Re: with 5.2 Mac
- To: mathgroup at smc.vnet.net
- Subject: [mg59827] Re: with 5.2 Mac
- From: sbjensen at midway.uchicago.edu (Steuard Jensen)
- Date: Tue, 23 Aug 2005 04:51:22 -0400 (EDT)
- Organization: The University of Chicago
- References: <de45i8$qtf$1@smc.vnet.net> <de6m64$ci0$1@smc.vnet.net> <200508210751.DAA26538@smc.vnet.net> <debsib$99l$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Regarding what seems like reduced success of Simplify and Refine
between version 5.0 and 5.2:
Quoth Andrzej Kozlowski <akoz at mimuw.edu.pl> in article
<debsib$99l$1 at smc.vnet.net>:
> On 21 Aug 2005, at 09:51, Steuard Jensen wrote:
> > In[1]:= $Assumptions = {Element[{x, y, w, z}, Reals]};
...
> > In[7]:= FullSimplify[Conjugate[(x+I y)(w+I z)]]
> > Out[7]= Conjugate[(x+I y) (w+I z)]
> > In[8]:= Refine[Conjugate[(x+I y)(w+I z)]]
> > Out[8]= Conjugate[(x+I y) (w+I z)]
> Now you are running into a different (though common) problem:
> LeafCount[Conjugate[(x + I*y)*(w + I*z)]]
> 16
> LeafCount[ComplexExpand[Conjugate[(x + I*y)*(w + I*z)]]]
> 19
> So the expanded expression is actually considered to be "more
> complicated" by the default complexity function.
Hmm. First of all, while this could explain the behavior of Simplify
and FullSimplify, I don't think that it would have anything to do with
the behavior of Refine that I quoted above. And in my eyes, if I
can't trust Refine to handle a simple factored quadratic, it's not
clear to me that it is useful at all.
But as for Simplify and FullSimplify, LeafCount[(x - I*y)*(w - I*z)] =
15, which _is_ less than 16. As Simplify doesn't call ComplexExpand,
I'm not sure that your example here is entirely relevant (note that
ComplexExpand seems to automatically group its result into real and
imaginary parts rather than factoring, which is what leads to the
higher LeafCount in this case).
Simplify _does_ call Refine, however (or at least, it's supposed to).
In version 5.0, calling Refine on this expression gives the factored
form (exactly as I would hope), which presumably has something to do
with Simplify getting the expected answer in that version.
> If you change the complexity function FullSimplify will behave as
> expected:
> FullSimplify[Conjugate[(x + I*y)*
> (w + I*z)], ComplexityFunction ->
> (LeafCount[#1] + 100*Count[#1, Conjugate,
> Infinity, Heads -> True] & )]
> (x - I*y)*(w - I*z)
But interestingly, ordinary Simplify still doesn't get this right,
even with the modified complexity function. My guess is that
FullSimplify is willing to spend more time applying transformations to
sub-expressions
> I am not actually convinced that the new behaviour of Simplify
> (surely not of FullSimplify) is unintentional. I suspect some
> transformations have been removed form Simplify to improve performance.
But what about the new behavior of Refine? I never got the impression
that its performance was especially in need of improvement. (But
then, I never tested it in detail, either.) I'm becoming increasingly
convinced that some change to Refine is responsible for much of this
odd behavior.
> If you do not like to use FullSimplify you could try to add
> transformations to Simplify (and also change the complexity function,
> for example to the one used above).
Well, thus far I've found that adding Refine to Simplify and also
using your suggested ComplexityFunction still doesn't work (even
though that ComplexityFunction does work for FullSimplify).
> One, perhaps radical, approach might be to add ComplexExpand in the
> following way. First we evaluate your assumptions:
That's not radical, that's pretty cool! I'd actually just make one
change to what you've suggested here for my purposes (now that I've
looked at the help file for ComplexExpand in more detail): I'd specify
TargetFunctions->Conjugate.
f[expr_Conjugate] := With[{vars = Cases[expr, _Symbol, Infinity]},
ComplexExpand[expr, Complement[vars,
Flatten[Cases[$Assumptions,
(x_) ? Reals :> (x /. Alternatives -> List), {1}]]],
TargetFunctions ->Conjugate]]
Then, f[Conjugate[x + I p]] = x - I Conjugate[p].
That may not _look_ simpler, but I'd much rather deal with conjugates
of my complex variables than with their real and imaginary parts. In
fact, in the relevant package that I've written (which implements
Grassmann variables using NonCommutativeMultiply and a bunch of
simplification routines), I've even modified Conjugate to return
specific names in this case: for example, "Conjugate[p] = pb", where
"pb" is a shorthand for "p bar". I also define "Conjugate[pb] = p",
of course.
This may end up being precisely the solution that I'm looking for.
Thanks! (It will mean rewriting at least some parts of the package,
but that's probably not so bad.)
(Of course, I'm still _curious_ to know what's up with Refine!)
Steuard Jensen
- References:
- Re: Simplifying Conjugate[] with 5.2 Mac
- From: sbjensen@midway.uchicago.edu (Steuard Jensen)
- Re: Simplifying Conjugate[] with 5.2 Mac