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

Re: Programming Options for Power Expand

• To: mathgroup at christensen.cybernetics.net
• Subject: [mg851] Re: Programming Options for Power Expand
• From: rubin at msu.edu (Paul A. Rubin)
• Date: Wed, 26 Apr 1995 00:18:21 -0400
• Organization: Michigan State University

In article <3mveno$r0s at news0.cybernetics.net>,
   Jack Goldberg <jackgold at math.lsa.umich.edu> wrote:
->I have received a number (1) of requests for my solution 
->to my own problem:  Enhance PowerExpand so that among 
->other things it simplifies  ArcTan[Tan[x]] = x.  The 
->real question is more general:  Should (and can!) one 
->add options to a built in command?  I do not know the 
->answer to whether one should.  I am interested in knowing 
->what is good Mma programming practice in this regard.
->Is what I present next poor programming practice?  Why?
->(I am most interested in the style, less in how to improve 
->my code.)
[chomp]
Well, I couldn't get into the Mma Style Police (flunked the typing speed 
requirement), but I'll offer an opinion on the "should" part (the answer to 
"can" is yes).  Rather than futz with the behavior of an internal command, 
I would probably define my own version of it and add options to that.  For 
instance:

  powerExpand[ x_ ] := PowerExpand[ x ]
  powerExpand[ ArcTan[Tan[x_]] ] := x
etc.

That way, I pick up two layers of protection:  in the short term (while I'm 
experimenting with the redefinition), I'm less likely to crash the kernel; 
and if I use some Mma package which in turn invokes the internal command, 
I'm not going to mess up its behavior.  IMHO it's pretty hard to predict 
what this sort of tinkering will do to other commands/packages.  Of course, 
the catch is that whatever improvements I make to the command will not show 
up when it's invoked by another command or package.  In the case of 
packages, though, I always have the option to substitute my version for the 
original in the source code.

I might add that, this opinion notwithstanding, I have messed with internal 
commands in the past.  I've got a package in which I essentially define a 
new data type, and I want to extend a bunch of standard operations (such as 
finding the minimum of a list) to it.  I didn't want to force the user to 
learn an entirely new set of functions for routine operations (e.g., use 
"myMin" rather than "Min"), so I went ahead and extended the internal 
functions.  For syntactic reasons, I could not use upvalues (which would 
associate the modifications with the data rather than the operator).  On 
the plus side, if my syntax is correct, the extensions will be invoked only 
when an object of the new data type is present as an argument, so I should 
not have diddled the operation of the internal commands on general 
arguments.  I hope.  Mightily.

Paul



**************************************************************************
* Paul A. Rubin                                  Phone: (517) 432-3509   *
* Department of Management                       Fax:   (517) 432-1111   *
* Eli Broad Graduate School of Management        Net:   RUBIN at MSU.EDU    *
* Michigan State University                                              *
* East Lansing, MI  48824-1122  (USA)                                    *
**************************************************************************
Mathematicians are like Frenchmen:  whenever you say something to them,
they translate it into their own language, and at once it is something
entirely different.                                    J. W. v. GOETHE