On Sep 11, 2009, at 9:38 PM, Stavros Macrakis wrote:
> On Fri, Sep 11, 2009 at 12:31 PM, ?iga Lenar?i?
> <ziga.lenarcic at gmail.com> wrote:
>
> Various versions of such functions have been posted on this mailing
> list over the years.
I will look through archives if I find anything..
>
> As you point out, the two big issues are the simplicity metric and
> calculation time. For small expressions, the calculation time may be
> only a second or two, but for large expressions the calculation time
> quickly becomes prohibitive. It would be nice if we could somehow
> time-limit subexpression calculations, but I don't think there is any
> reliable way of doing that.
One way to partially remedy this is to be careful which
transformations you make - some might bear fruit, some might not - in
some cases that can be cheaply determined... in the end it's still
brute force ofcourse.
Optional time limit is possible just not too robust. Time can be
checked on each call in recursion and if the time limit is crossed,
only the cheapest transformations are tried or the search is stopped
and the 'best' expression so far is returned..
>
> And of course many useful transformations will not be found anyway.
> For instance, I don't know of any practical way to perform
> "simplifications" like x^5-14*x^4+94*x^3-264*x^2+409*x-242 =>
> (x+1)^4+(x-3)^5.
But I wouldn't expect any human to do that either :)
I think the goal of 'simplify' is merely to do 'trivial stuff' as you
would by hand, but to do it instead of the user. No, simplify doesn't
bring anything new that can be calculated by Maxima, it's pure
convenience function - but that matters a lot to the user usually.
Tools are not only about power, ease of use is often even more
important generally speaking.
>
> -s
Regards,
Ziga