Re: About Simplify
- To: mathgroup at smc.vnet.net
- Subject: [mg59694] Re: About Simplify
- From: David Bailey <dave at Remove_Thisdbailey.co.uk>
- Date: Thu, 18 Aug 2005 00:16:27 -0400 (EDT)
- References: <200508160939.FAA10679@smc.vnet.net> <ddur65$odd$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Curtis Osterhoudt wrote: > Hi, Peltio, > > I tried a direct response, but my demunging wasn't crafty enough for > your email's reply-to. > > The documentation for TransformationFunctions (with which I haven't > played, but wish I knew about far, far earlier) indicates that if the > user includes a list of transformations to try, only those are used. It > seems that it gets at the problem of strange outputs from just the other > direction of what you're suggesting. > > I would guess that if a user knows exactly the form she wants, and can > express this correctly in a function, the built-in > TransformationFunctions would be more appropriate. However, as you say, > often the form the user wants isn't predetermined, but the user > certainly knows which forms he or she don't want, especially after > seeing them returned by Simplify. > > My final thought is that in its implementation, your method would have > to include some transformations of the form that TransformationFunctions > requires; otherwise, Mathematica would just have a restricted set of > transformations from what it usually tries, and will, almost always, > return the original expression, unevaluated. Of course, I don't know the > code's true structure, and so can't be sure. > > Regards, > C.O. > > Peltio wrote: > > >>The recent threads about Simplify made me wonder why the user is not allowed >>to choose which transformation rules apply to the expression passed to it. >>Of course Simplify and FullSimplify are no longer (if they ever were) >>written in Mathematica code, but is it at all impossible to rewrite its >>interface in order to let the user interact with the builtin code? >> >>I do not know the way the code is structured for these procedures, but I can >>guess that at a certain point it will try to apply certain sets of rules >>having to do with trigonometric functions, Bessel functions, Hypergeometric >>functions and many other more or less exotic special functions. >>Is there no way at all to put switches to disable certain sets of rules? >>(A question for developers, of course - I do not think that Mathemaitca >>users can interact with the code). >> >>The user could pass a list of exclusion rules, such as >> >> Simplify[ expr, BesselFunctions->False, AiryFunctions->False, >>ErfFunctions->False] >> >>when the results he gets contain certain special functions he does not want >>to involve. The overhead for multiple switches will be minimal (the >>procedure will have to modify a table which will be looked up by the >>internal C code) and the user will be able to build custom simplify >>solutions (one that uses only algebraic and trigonometric functions, one >>that uses the orthogonal polynomials, one tht does not use hypergeometric >>functions and so on). >> >>I can imagine that the built-in code is not a sequence of transormation >>rules to apply in chain one after the other, but perhaps many special >>functions rules could be switched on and off at will without afffecting the >>remaining code. >>Or is it completely unthinkable? >> >>just wondering, >>Peltio >>Invalid address in reply-to. Crafty demunging required to mail me. >> >> >> >> > > Hi, In fact, if you look at the documentation for the TransformationFunctions option (at least at 5.1), you can include the default transformations as well by adding the Automatic option to the list. The other thing to consider here is writing a function to try exactly the operations you require - possibly calling Simplify internally to finish the process off. David Bailey http://www.dbaileyconsultancy.co.uk
- References:
- About Simplify
- From: "Peltio" <peltio@trilight.zone>
- About Simplify