Re: Re: unable to FullSimplify

*To*: mathgroup at smc.vnet.net*Subject*: [mg65969] Re: [mg65945] Re: unable to FullSimplify*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Tue, 25 Apr 2006 05:18:39 -0400 (EDT)*References*: <200604160545.BAA07958@smc.vnet.net> <200604181056.GAA14321@smc.vnet.net> <e24uhn$5s7$1@smc.vnet.net> <200604200914.FAA05331@smc.vnet.net> <e29qvc$m59$1@smc.vnet.net> <200604241001.GAA08924@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

On 24 Apr 2006, at 19:01, Vladimir wrote: > Andrzej Kozlowski wrote: >>> In[]:= subdivide[a_ + b_] := FullSimplify[a] + FullSimplify[b]; >>> FullSimplify[Expand[x + (x + x^2)^4], >>> TransformationFunctions -> {Automatic, subdivide}] >>> Out[]= x + x^4*(1 + x)^4 >> >> Well, yes, it works nicely here but the question is, if you make this >> a default transformation transformation for FullSimplify how will it >> effect complexity? > > Some option to FullSimplify would be enough for this to be used only > when needed. Anyway, it was just one quick and arbitrary example > to show that FullSimplify can be improved without too much effort > > >> In fact it even seems hard to see how you would avoid numerous >> unnecessary attempts at simplifying the same expression... > > That's quite normal it seems. For example, to simplify just a+b, > ComplexityFunction is called 28 times(!) Here's a proof: > > reveal[expr_] := (Print[expr]; LeafCount[expr]) > FullSimplify[a + b, ComplexityFunction -> reveal] > > >> Some more thoughts: if your subdivide were really a default >> transformation in FullSimplify it may well lead to an infinite loop, >> since it would be calling on itself. > > Are you sure? This subdivide reduces its argument on each > invocation so I don't see how infinite loop can be possible. > I couldn't find any examples with such a problem. > > >> Note however also the folowing interesting feature: >> >> u = Expand[x + (x + x^2)^4]; >> >> FullSimplify[f[u] == f[x + (x + x^2)^4]] >> >> True > > Well, since f[a]==f[a] evaluates to True, Mathematica simplifies > the above equation because it is able to prove equality of f's > arguments. > > -- > Vladimir > As far as I can tell your last statement is vacuous; it essentially says : it happens because it happens. The true reason is actually quite complicated, as was explained in Adam Strzebonski's post. I am amazed you missed or ignored his reply to this thread since he posted it to the list and also sent to you personally. Also, you can trust him in this matter much more than me or anyone else, since not only is he the programmer of FullSimplify, but also a very good mathematician and an expert in exactly the kind of mathematics that FullSimlify relies on. Since he also did not choose to contradict my other points I think they are basically correct, except perhaps the one about the possibility of an infinite loop. (I thought that your transformation together with some other transformation used by FullSimplify might result in an infinite loop, but I have not been able to find any obvious example). Of course some things are not a matter of mathematics or programming but simply design decisions. One of these is that FullSimplify has Automatic as the only built in value for the option TransformationFunctions with other values being left to the user. It might be that one could add one or two collections of particularly useful but high time complexity transformations for some specific purposes. I am sure however that not doing so was a carefully considered decision. Finally, I must say I am not a little shocked that anyone can believe that FullSimplify could be improved so easily, but as I do not get paid to argue about this, I will leave it at that ... Andrzej Kozlowski

**References**:**unable to FullSimplify***From:*vladimir347@yahoo.com

**Re: unable to FullSimplify***From:*"Vladimir" <vladimir347@yahoo.com>

**Re: unable to FullSimplify***From:*"Vladimir" <vladimir347@yahoo.com>

**Re: unable to FullSimplify***From:*"Vladimir" <vladimir347@yahoo.com>