Re: Re: locally changing Options
- To: mathgroup at smc.vnet.net
- Subject: [mg108323] Re: [mg108293] Re: [mg108224] locally changing Options
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Sat, 13 Mar 2010 07:59:46 -0500 (EST)
- References: <5310030.1268308256178.JavaMail.root@n11>
Hi David,
Your suggestion was the first thing that came also to my mind. But there may
be instances where you don't want to do it, particularly when RowReduce (or
whatever function) is a part of larger functionality to which you either
don't have access or which you don't want to change/rewrite (for example, it
is a part of the larger functionality that you use out-of-the-box, but you
want to see how it behaves in different regimes, in a well-controlled
fashion). The problem is that your construct scopes lexically, therefore I
can not programmatically hunt invocations and replace RowReduce by rowReduce
at run-time. OTOH, if I use Block[{RowReduce = rowReduce},...] or something
like that, this goes into infinite iteration since I can not "unblock"
RowReduce. I've suggested two ways out but neither one is completely robust.
By the way, this is not the first time that I feel a need for something like
Unblock[{symbol}, code], which would allow us to get the global (previously
blocked) value back to use in code executed upper in the call stack (with
respect to code where the symbol has been Block-ed), so that one would be
able to use dynamic scoping in a "concentric spheres" - like fashion.
Unblocked symbols can be Block-ed again (if needed) still upper in the call
stack, and so on.
Here is how it might look:
ClearAll[executeWithOptions];
SetAttributes[executeWithOptions, HoldFirst];
executeWithOptions[code_, fn_Symbol, opts___?OptionQ] :=
Module[{localF},
localF[args___] := fn[args, opts];
Block[{fn},
fn[args___] := Unblock[{fn}, localF[args]];
code]];
and one could use it as
executeWithOptions[whatever-code-you-want, RowReduce, Method ->
"OneStepRowReduction"].
I've seen other occasions where such construct might be useful. Who knows,
may be some day it will appear in the new version. But I am pessimistic
since it seems that programming based on dynamic scoping is generally
frowned upon (a pity IMO. This seems a very powerful technique, although
admittedly also error-prone and non-transparent).
Regards,
Leonid
On Fri, Mar 12, 2010 at 3:14 PM, David Park <djmpark at comcast.net> wrote:
> An interesting question. I don't know of a good way to use Block on an
> Option value. Maybe someone will come up with a solution.
>
> I assume that within foo you are using RowReduce a number of times so you
> don't want to write the specific option value each time. Why not define
> your
> own local version of RowReduce for the foo routine?
>
> foo[x_]:=
> Module[{rowReduce}
> rowReduce[mat_]:= RowReduce[mat, Method -> "OneStepRowReduction"];
> ...;
> rowReduce[x]]
>
>
> David Park
> djmpark at comcast.net
> http://home.comcast.net/~djmpark/ <http://home.comcast.net/%7Edjmpark/>
>
>
> From: hemmecke [mailto:hemmecke at gmail.com]
>
>
> In a function I'd like to temporarily say
>
> foo[x_]:=Module[{...},
> ...
> SetOptions[RowReduce, Method->OneStepRowReduction];
> ...
> ]
>
> without affecting the global setting for RowReduce when I call foo.
>
> My experiments wrapping the SetOptions with a Block structure were not
> fruitful so far.
> The only thing I can think of is something of the form
>
> method = Options[RowReduce, Method];
> SetOptions[RowReduce, Method->OneStepRowReduction];
> ... do something ...
> SetOptions[RowReduce,method]
>
> But that looks ugly.
>
> Any suggestions with built-in Mathematica features to achieve this kind of
> locality.
>
> Ralf
>
>
>
>