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