[Date Index] [Thread Index] [Author Index]
Re: Hyperbolic function identity
Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote in message news:<cjj840$bsd$1 at smc.vnet.net>... > Ah, of course! Well, it was late last night! > Still, I think this explains the whole problem, and also shows that > with the present paradigm on which Simplify and FullSimplify are based > it is unavoidable. > > To summarise it: with a given complexity function and the presence of > conditions in Simplify or FullFimplify, the transformation leading to > the "simplest result' (in this case 0) may have to use a step which > results in an expression which has a higher complexity (in this case > the expression involving logs, which has a higher default complexity > until it itself is simplified under the given assumptions). Clearly, > this is un-avoidable, since to avoid it Mathematica should test each > intermediate expression that any of its trasformation functions > produces by again applying FullSimplify with assumptions. IN other > words it would would have to do something like this: > Can this long discussion be summarized as follows: The paradigm of using a leaf-based complexity function as simplification driver is wrong. I happen to be interested in the subject because more of 80% of the problems I have experienced with Mathematica since 1994 are due to Simplify, and more recently FullSimplify. The main difficulties are o Excessive time requiring user abort Note 1: specifying a TimeConstraint, which appeared in 3.1, does not work as regards limiting total time Note 2: my feeling is that the tree-traversal algorithm used has exponential complexity in the number of leaves, but I have no timing tests to back that estimate. o Outside coaching to tunnel out from local minima. Simplify should be a black box. Tunneling algorithms are well known in the MP community.