MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: About Simplify

  • To: mathgroup at smc.vnet.net
  • Subject: [mg59674] Re: About Simplify
  • From: Curtis Osterhoudt <gardyloo at mail.wsu.edu>
  • Date: Wed, 17 Aug 2005 04:00:27 -0400 (EDT)
  • References: <200508160939.FAA10679@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

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.
>
>
>  
>

-- 
PGP Key ID: 0x235FDED1
Please avoid sending me Word or PowerPoint attachments.
http://www.gnu.org/philosophy/no-word-attachments.html


  • Prev by Date: Problem with Mathematica 5.2 on G5 Macintosh Systems
  • Next by Date: Re: How to specify boundary conditions on all 4 sides of a plate for a steady state heat equation (PDE) using NDSolve? (Laplace equation)
  • Previous by thread: Re: About Simplify
  • Next by thread: Re: About Simplify