Re: replacement rules in packages
- To: mathgroup@smc.vnet.net
- Subject: [mg11291] Re: [mg11235] replacement rules in packages
- From: David Withoff <withoff@wolfram.com>
- Date: Wed, 4 Mar 1998 01:39:44 -0500
> My problem lies with replacement rules in packages. I have created
> functions that use replacement rules both to utilize option arguments
> as well as to get parameter values from built-in functions that have
> answers in the form {a -> 20, b -> 30}. If I test my function in a
> plain notebook, all is fine. If I make it a package following all the
> info I found in Maeder, Tam, and others, it does not work. This has
> happened twice to me recently, and the problem seems to lie with the
> repalcement rules in the package. I have attached three files:
>
> sinefit2.nb - the function in a notebook, where it works fine TrigFit.m
> - the package version
> trial.nb - a notebook to check the package - lots of error messages
>
> I am at the end of my wits - does anybody know how to fix this problem?
>
> Please email me at silvi@cinenet.net or if you use reply, make sure to
> take out the nospam.
>
> Thanks a lot
>
> Silvia
This type of problem can be resolved by considering all of the
constructs in the program that affect localization of symbols
(BeginPackage, Begin, Module, etc.). This analysis will normally
expose one or more symbols that are in different localization
environments, but that are mistakenly expected to refer to the same
variable. For example, the symbol y in
Module[{y}, y = 5]
refers to a different variable than does the symbol y in
Module[{y}, x + y]
so the value assigned to y in the first Module will not be used in the
second Module. In this example the distinction between the two uses of
y is probably obvious, but in more elaborate programs the problem isn't
always as obvious.
Here, in the example that does what you want, the structure is
---------------------------------------------------------------
SineFit[...]:=
Module[{...,minx,maxx,miny,maxy...},
Options[SineFit] = {xplot -> {minx,maxx},yplot -> {miny,maxy}};
minx = ... ;
maxx = ... ;
miny = ... ;
maxy = ... ;
]
-----------------------------------------------------------------
and in the example that does not do what you want, the structure is:
----------------------------------------------------------------
BeginPackage["TrigFit`"]
Options[SineFit] = {xplot -> {minx,maxx},yplot -> {miny,maxy}}
Begin["`Private`"]
SineFit[...]:=
Module[{...,minx,maxx,miny,maxy...},
minx = ... ;
maxx = ... ;
miny = ... ;
maxy = ... ;
]
End[]
EndPackage[]
----------------------------------------------------------------
In the first example, the symbols minx, ..., used in Options[SineFit]
occur inside the Module, and refer to a local variable in the Module.
In the second example, the symbols minx, ..., used in Options[SineFit]
occur both outside the Module, where they refer to symbols that are
exported by the package, and inside the Module, where they refer to
local variables of the Module.
If you move the assignment to Options[SineFit] in the first example
outside the Module, then that example will behave like the second
example. Similarly, if you drop the symbols minx, ..., from the local
variable list in the Module in the second example, then those variables
will refer to the exported symbols of the package, and the second
example will behave like the first example.
If you want your package to follow Mathematica design conventions, then
I would recommend a third approach, which is to dispense with the
exported symbols minx, maxx, ..., and to use Automatic as the option
value when the value is constructed using default code within your
program.
Dave Withoff
Wolfram Research