locally changing Options
hemmecke
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
Leonid Shifrin
To my knowledge, there is no built-in functionality that would immediately
solve your problem. One way is to automate the steps you mentioned, for
example like this:
ClearAll[withOptions];
SetAttributes[withOptions, HoldFirst];
withOptions[code_, f_, opts : {__?OptionQ}] :=
Module[{old = Options[f], result},
SetOptions[f, opts];
result = code;
SetOptions[f, old];
result];
Here is a test function for an illustration:
ClearAll[fn];
Options[fn] = {Display -> False};
fn[x_, y_, opts___?OptionQ] :=
If[TrueQ[Display /. Flatten[{opts}] /. Options[fn]],
Print[x, " ", y]; x + y,
x + y];
and this is some function which stands for the entire code you want to
execute with a different option setting:
ClearAll[myFunction];
myFunction[] := fn[1, 2]^2;
Here is how you can use it:
In[868]:= myFunction[]
Out[868]= 9
In[869]:= withOptions[myFunction[], fn, {Display -> True}]
During evaluation of In[869]:= 1 2
Out[869]= 9
The advantage of this approach is that it is simple and straightforward. The
disadvantage however is not even that this "looks ugly", since we automated
these steps, but that if an exception is thrown or Abort[] happens in the
middle of your code, you end up with your option not changed back to what it
was. This can be dealt with in this approach, but it will become more
complex.
There is another approach that I use sometimes, based on dynamic scoping and
local option passing. I wrote a tiny package which allows .to "subscribe"
any given function to be a receiver of some "global" options. Here it is:
(* ::Package::*)
BeginPackage["OptionPipe`"];
OptionPipe::usage =
"OptionPipe is a wrapper that allows to propagate options
non-locally";
OptionsInPipe::usage =
"OptionsInPipe[f_] returns options currently in OptionPipe";
SubscribeToPipe::usage =
"SubscribeToPipe[fun_] makes the options present in pipe
at the moment of the call, to be passed to <fun>";
UnsubscribeFromPipe::usage =
"UnsubscribeFromPipe[fun_] removes the \"subscription\"
to OptionPipe for <fun>";
Begin["`Private`"];
$OptionsInPipe = {};
(* Declare symbol in the `Private` scope *)
subscribed;
OptionPipe /: f_[args___, OptionPipe[opts___?OptionQ]] :=
Block[{$OptionsInPipe = {opts}}, f[args]];
OptionsInPipe[fun_] := $OptionsInPipe;
unsubscribedQ[fun_] := FreeQ[DownValues[fun], subscribed];
SubscribeToPipe[fun_Symbol?unsubscribedQ] :=
With[{protected = Unprotect[fun]},
PrependTo[DownValues[fun],
HoldPattern[
fun[args___ /; Not[Or @@ (OptionQ /@ {args})], opts___?OptionQ]
/; (subscribed;
True) && (Complement[OptionsInPipe[fun], {opts}] =!= {})] :>
fun[args, Sequence @@ OptionsInPipe[fun], opts]];
Protect[protected]];
UnsubscribeFromPipe[fun_] :=
DownValues[fun] =
DeleteCases[DownValues[fun], def_ /; Not[FreeQ[def, subscribed]]];
End[];
EndPackage[];
In this way, you don't touch global Options[function] at all, but pass some
options to a function locally during each function call, for those functions
which are "subscribed". Note that I didn't do option filtering above, which
is a bit sloppy on my side, but that can be easily added. Here is how you
can use it:
In[885]:= SubscribeToPipe[fn];
In[886]:= myFunction[]
Out[886]= 9
In[887]:= myFunction[OptionPipe[Display -> True]]
During evaluation of In[887]:= 1 2
Out[887]= 9
You can see that DownValues of the subscribed function have been modified
during "subscription":
In[889]:= DownValues[fn]
Out[889]= {HoldPattern[
fn[OptionPipe`Private`args$___ /; !
Or @@ OptionQ /@ {OptionPipe`Private`args$},
OptionPipe`Private`opts$___?
OptionQ] /; (OptionPipe`Private`subscribed; True) &&
Complement[
OptionsInPipe[fn], {OptionPipe`Private`opts$}] =!= {}] :>
fn[OptionPipe`Private`args$, Sequence @@ OptionsInPipe[fn],
OptionPipe`Private`opts$],
HoldPattern[fn[x_, y_, opts___?OptionQ]] :>
If[TrueQ[Display /. Flatten[{opts}] /. Options[fn]],
Print[x, " ", y]; x + y, x + y]}
When you "unsubscribe", you get back the original defs:
In[891]:= UnsubscribeFromPipe[fn];
In[892]:= DownValues[fn]
Out[892]= {HoldPattern[fn[x_, y_, opts___?OptionQ]] :>
If[TrueQ[Display /. Flatten[{opts}] /. Options[fn]],
Print[x, " ", y]; x + y, x + y]}
The disadvantage of this approach is that the global definitions of the
subscribed functions get modified during all of the "subscription" period.
The advantage is that you pass options locally and have no chance to end up
with options having changed globally. Another advantage is that you can turn
"subscription" on and off dynamically at run-time, so this is more flexible.
Neither one is completely robust, but they worked for me so far. Regarding
their status, IMO both are hacks. I won't be at all surprised if someone
suggests some better method than any of these two.
Regards,
Leonid
.
Daniel Lichtblau
> 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
The way we do this in house is close to what you show. We simply enclose
the sequence of before,work,after code within a special wrapper function
called WithLocalSettings (in Internal` context). This forces the cleanup
phase to happen even when there might be an interrupt (e.g. from an
outer TimeConstrained). In your example it would be done as below.
Internal`WithLocalSettings[
method = Options[RowReduce, Method];
SetOptions[RowReduce, Method->OneStepRowReduction]
, (* now perform main task *)
... do something ...
, (* now cleanup *)
SetOptions[RowReduce,method]
]
It is certainly possible that this will migrate to a different context
in a future release. But this functionality is not going to be removed,
as we use it in far too many places.
Daniel Lichtblau
Wolfram Research
Peter Pein
> 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.
>
>
> Ralf
>
Hi Ralf,
There is a package "BlockOptions" at
http://library.wolfram.com/infocenter/MathSource/5549/
It is used like (you might want to know before downloading):
BlockOptions[{RowReduce},
SetOptions[RowReduce, what->ever, you->like];
... RowReducing over and over again ...
(* simply close the bracket and don't worry what you've done to the
options of any of the functions in the list above *)
]
Peter
Raffy
f
> locality.
>
> Ralf
Block[
{RowReduce = RowReduce[#1, Method -> "OneStepRowReduction", ##2] &},
(* your code here *)
]
David Park
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
djm...@comcast.net
http://home.comcast.net/~djmpark/
From: hemmecke [mailto:hemm...@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
David Park
It is always nice to have someone good at computer science to steer us away
from the shoals!
But sometimes the general is the enemy of the useful. In most cases like
this the user really would be doing all the RowReduce manipulations
explicitly. The general solution is going to be much more abstract and
difficult to remember or implement. And in the case of implicit use of
RowReduce other considerations might also come in. Suppose a ConditionMatrix
routine from some other package was being used and this contained calls to
RowReduce. How do you know that ConditionMatrix isn't using specific
settings of Method? It looks to me that your method would override these.
(Or am I mistaken there?) If ConditionMatrix allowed a choice of Method,
then it should take it as an argument or have its own Options. One is trying
to overcome poor package design.
What do you think of Daniel Lichtblau's Internal`WithLocalSettings? That
seems to work without passing options, so if ConditionMatrix used an
explicit Method option it would not be overridden.
David Park
http://home.comcast.net/~djmpark/
From: Leonid Shifrin [mailto:lsh...@gmail.com]
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 <djm...@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
djm...@comcast.net
http://home.comcast.net/~djmpark/ <http://home.comcast.net/%7Edjmpark/>
Leonid Shifrin
But sometimes the general is the enemy of the useful. In most cases like
> this the user really would be doing all the RowReduce manipulations
> explicitly. The general solution is going to be much more abstract and
> difficult to remember or implement.
>
I fully agree with you. In most cases using dynamic scoping is probably an
overkill and will bring more trouble than it is worth. I just have a feeling
that it has great potential when used thoughtfully in some well-defined
setting, and such that its workings are encapsulated and "protected" from
the end user. I also feel that it is better suited for temporal changes in
global properties, since when we use it we are guaranteed by the language
itself that we will not mess up the global state regardless of what sudden
interrupts can occur during the evaluation of the code.
> And in the case of implicit use of RowReduce other considerations might
> also come in. Suppose a ConditionMatrix routine from some other package was
> being used and this contained calls to RowReduce. How do you know that
> ConditionMatrix isn't using specific settings of Method? It looks to me that
> your method would override these. (Or am I mistaken there?)
>
Well, if that function (ConditionMatrix say) passes options explicitly to
RowReduce (and I think that this, rather than the change of global option
settings, is the right way to do it) , then those options will be part of
<args>, and since they come before <opts> in my function call, they will be
favored, not <opts>. So, passing an explicit Method option should work fine.
If, on the other hand, that function modifies Options[RowReduce] globally,
then yes, my code will override it. But I think that changing options
globally is generally a bad programming style anyway.
> If ConditionMatrix allowed a choice of Method, then it should take it as an
> argument or have its own Options. One is trying to overcome poor package
> design.
>
Agree completely.
> What do you think of Daniel Lichtblau's Internal`WithLocalSettings? That
> seems to work without passing options, so if ConditionMatrix used an
> explicit Method option it would not be overridden.
>
As far as I can tell, this is the best solutiuon available. If I knew about
it, I would not bother posting any of my suggestions. Actually, some time
ago for my purposes I wrote a version which seems to have similar
functionality to Internal`WithLocalSettings, but it's not exactly simple or
brief. In view of Daniel's suggestion, I am glad I did not post it.
Have a nice weekend,
Leonid
>
>
>
>
> David Park
>
> djm...@comcast.net
>
> http://home.comcast.net/~djmpark <http://home.comcast.net/%7Edjmpark>/
>
>
>
>
>
>
>
> *From:* Leonid Shifrin [mailto:lsh...@gmail.com]
> I've seen other occasions where such construct might be useful. Who know=
> Any suggestions with built-in Mathematica features to achieve this kind o=
f
> locality.
>
> Ralf
>
>
>
>
--0015174c3a9670202d0481a13174
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Sun-Content-Length: 9959
Hi David,<br><br><div class="gmail_quote"><blockquote class="gmail_quot=
e" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-U=
S"><div><p class="MsoNormal">
<span style="color: black;">But
sometimes the general is the enemy of the useful. In most cases like this t=
he
user really would be doing all the RowReduce manipulations explicitly. The
general solution is going to be much more abstract and difficult to remembe=
r or
implement. </span></p></div></div></blockquote><div>I fully agree with y=
ou. In most cases using dynamic scoping is probably an
overkill and will bring more trouble than it is worth. I just have a
feeling that it has great potential when used thoughtfully in some
well-defined setting, and such that its workings are encapsulated and "=
;protected" from
the end user. I also feel that it is better suited for temporal changes in =
global properties, since when we use it we are guaranteed by the language i=
tself that we will not mess up the global state regardless of what sudden i=
nterrupts can occur during the evaluation of the code.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid =
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div lin=
k="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><spa=
n style="color: black;">And in the case of implicit use of RowReduce othe=
r
considerations might also come in. Suppose a ConditionMatrix routine from s=
ome
other package was being used and this contained calls to RowReduce. How do =
you
know that ConditionMatrix isn=92t using specific settings of Method? It
looks to me that your method would override these. (Or am I mistaken
there?) </span></p></div></div></blockquote><div>Well, if that function (<s=
pan style="color: black;">ConditionMatrix say</span>) passes options expl=
icitly to RowReduce (and I think that this, rather than the change of globa=
l option settings, is the right way to do it) , then those options will =
be part of <args>, and since they come before <opts> in my func=
tion call, they will be favored, not <opts>. So, passing an explicit =
Method option should work fine. If, on the other hand, that function modifi=
es Options[RowReduce] globally, then yes, my code will override it. But I=
think that changing options globally is generally a bad programming sty=
le anyway.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link=
="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span=
style="color: black;">If ConditionMatrix allowed a choice of Method, the=
n it should take it
as an argument or have its own Options. One is trying to overcome poor pack=
age
design.</span></p></div></div></blockquote><div>Agree completely.</div><blo=
ckquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204,=
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vl=
ink="purple" lang="EN-US">
<div><p class="MsoNormal"><span style="color: black;"></span></p>
<p class="MsoNormal"><span style="color: black;">What
do you think of Daniel Lichtblau=92s Internal`WithLocalSettings? That seems
to work without passing options, so if ConditionMatrix used an explicit Met=
hod
option it would not be overridden.</span></p></div></div></blockquote><div>=
As far as I can tell, this is the best solutiuon available. If I knew about=
it, I would not bother posting any of my suggestions. Actually, some time =
ago for my purposes I wrote a version which seems to have similar functiona=
lity to <span style="color: black;">Internal`WithLocalSettings</span>, bu=
t it's not exactly simple or brief. In view of Daniel's suggestion,=
I am glad I did not post it. <br>
<br>Have a nice weekend,<br><br>Leonid<br> </div><blockquote class="gma=
il_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0=
pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang=
="EN-US">
<div><div>
<p class="MsoNormal"><span style="color: black;"> </span></p>
<p class="MsoNormal"><span style="color: black;"> </span></p>
<p class="MsoNormal"><span style="color: black;">David
Park</span></p>
<p class="MsoNormal"><span style="color: black;"><a href="mailto:djmp=
a...@comcast.net" target="_blank">djm...@comcast.net</a></span></p>
<p class="MsoNormal"><span style="color: black;"><a href="http://home=
.comcast.net/%7Edjmpark" target="_blank">http://home.comcast.net/~djmpark=
</a>/ </span><span style="font-size: 14pt; color: black;"> </span><span=
style="color: black;"></span></p>
<p class="MsoNormal"><span style="color: black;"> </span></p>
<p class="MsoNormal"><span style="color: black;"> </span></p>
<p class="MsoNormal"><span style="color: black;"> </span></p>
</div><div style="border-style: solid none none; border-color: rgb(181, 1=
96, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium =
medium; padding: 3pt 0in 0in;">
<p class="MsoNormal"><b><span style="font-size: 10pt;">From:</span></b>=
<span style="font-size: 10pt;"> Leonid Shifrin
[mailto:<a href="mailto:lsh...@gmail.com" target="_blank">lshifr@gmail.=
com</a>] <br>
<br>
</span></p>
</div><div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom: 12pt;">Hi David, <br>
<br>
Your suggestion was the first thing that came also to my mind. But there ma=
y be
instances where you don't want to do it, particularly when RowReduce (o=
r
whatever function) is a part of larger functionality to which you either do=
n'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 ro=
bust. <br>
<br>
By the way, this is not the first time that I feel a need for something lik=
e
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 a=
ble
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.<br>
<br>
Here is how it might look:<br>
<br>
ClearAll[executeWithOptions];<br>
SetAttributes[executeWithOptions, HoldFirst];<br>
executeWithOptions[code_, fn_Symbol, opts___?OptionQ] :=<br>
Module[{localF},<br>
localF[args___] := fn[args, opts];<br>
Block[{fn},<br>
fn[args___] := Unblock[{fn}, localF[args]];<br>
code]];<br>
<br>
and one could use it as <br>
<br>
executeWithOptions[whatever-code-you-want, RowReduce, Method ->
"OneStepRowReduction"].<br>
<br>
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 pessimis=
tic
since it seems that programming based on dynamic scoping is generally frown=
ed
upon (a pity IMO. This seems a very powerful technique, although
admittedly also error-prone and non-transparent).<br>
<br>
Regards,<br>
Leonid<br>
<br>
<br>
<br>
</p>
</div><div><div><div>
<p class="MsoNormal">On Fri, Mar 12, 2010 at 3:14 PM, David Park <<a h=
ref="mailto:djm...@comcast.net" target="_blank">djm...@comcast.net</a=
>> wrote:</p>
<p class="MsoNormal">An interesting question. I don't know of a good =
way to use
Block on an<br>
Option value. Maybe someone will come up with a solution.<br>
<br>
I assume that within foo you are using RowReduce a number of times so you<b=
r>
don't want to write the specific option value each time. Why not define=
your<br>
own local version of RowReduce for the foo routine?<br>
<br>
foo[x_]:=<br>
Module[{rowReduce}<br>
rowReduce[mat_]:= RowReduce[mat, Method ->
"OneStepRowReduction"];<br>
...;<br>
rowReduce[x]]<br>
<br>
<br>
David Park<br>
<a href="mailto:djm...@comcast.net" target="_blank">djm...@comcast.ne=
t</a><br>
<a href="http://home.comcast.net/%7Edjmpark/" target="_blank">http://ho=
me.comcast.net/~djmpark/</a><br>
<br>
<br>
From: hemmecke [mailto:<a href="mailto:hemm...@gmail.com" target="_bla=
nk">hemm...@gmail.com</a>]</p>
<div>
<p class="MsoNormal" style="margin-bottom: 12pt;"><br>
<br>
In a function I'd like to temporarily say<br>
<br>
foo[x_]:=Module[{...},<br>
...<br>
SetOptions[RowReduce, Method->OneStepRowReduction];<br>
...<br>
]<br>
<br>
without affecting the global setting for RowReduce when I call foo.<br>
<br>
My experiments wrapping the SetOptions with a Block structure were not<br>
fruitful so far.<br>
The only thing I can think of is something of the form<br>
<br>
method = Options[RowReduce, Method];<br>
SetOptions[RowReduce, Method->OneStepRowReduction];<br>
... do something ...<br>
SetOptions[RowReduce,method]<br>
<br>
But that looks ugly.</p>
</div>
<p class="MsoNormal" style="margin-bottom: 12pt;">Any suggestions with =
built-in
Mathematica features to achieve this kind of<br>
locality.<br>
<br>
Ralf<br>
<br>
<br>
</p>
</div>
<p class="MsoNormal"> </p>
</div></div></div>
</div>
</blockquote></div><br>
--0015174c3a9670202d0481a13174--
DrMajorBob
Bobby
On Fri, 12 Mar 2010 06:12:37 -0600, Raffy <adr...@gmail.com> wrote:
> On Mar 11, 3:34 am, hemmecke <hemme...@gmail.com> wrote:
>> o=
> f
>> locality.
>>
>> Ralf
>
> Block[
> {RowReduce = RowReduce[#1, Method -> "OneStepRowReduction", ##2] &},
> (* your code here *)
> ]
>
Raffy
> On Mar 11, 3:34 am, hemmecke <hemme...@gmail.com> wrote:
>
>
>
>
>
> > 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.
>
o=
> f
> > locality.
>
> > Ralf
>
> Block[
> {RowReduce = RowReduce[#1, Method -> "OneStepRowReduction", ##2] &},
> (* your code here *)
> ]
A few people emailed me today, noting that my solution above, while
simple, doesn't work and results in infinite recursion. I apologize
for not testing my solution.
Anyway, after thinking about it, I felt that the simple fix would be:
Block[{RowReduce=System`RowReduce[#1,Method->...,##2]&}, ...]
However, this also results in recursion. Something seems odd: how is
the blocked RowReduce scoping the fully qualified symbol
System`RowReduce? (Looking at the Trace, it appears that it is
dropping the System` context prior to evaluation...)
This works: Block[{Print=System`Print},Print[1]];
This doesn't: Block[{Print=System`Print[##] &}, Print[1]];
Really odd behavior can be found using the following:
Let $ContextPath = { ..., "Temp`", ..., "System`", ... }
Block[{Temp`Print=System`Print[1, ##] &}, Print[2]] will print "12"
and also cause Print to become shadowed.
I guess the problem boils down to: Why does System`Print simplify to
Print?
Leonid Shifrin
Interesting - I never tried this package out. It however has a fault of not
protecting against exceptions being thrown somewhere in the code. I just
tried it and found that in this case the option of interest gets globally
changed after the code executes. With that fixed, this package may be a good
option.
Regards,
Leonid
On Fri, Mar 12, 2010 at 3:11 PM, Peter Pein <pet...@dordos.net> wrote:
> Am 11.03.2010 12:34, schrieb hemmecke:
> > 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.
> >
Leonid Shifrin
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 <djm...@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
> djm...@comcast.net
> http://home.comcast.net/~djmpark/ <http://home.comcast.net/%7Edjmpark/>
>
>
> From: hemmecke [mailto:hemm...@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
>
>
>
>
Leonid Shifrin
since you can not unblock a symbol once it is blocked (a pity b.t.w), and
Mathematica evaluates heads of expressions before anything else.
Regards,
Leonid
Raffy
> On Mar 12, 4:12 am, Raffy <adra...@gmail.com> wrote:
>
>
>
>
>
>
> > > 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.
>
> o=
> > f
> > > locality.
>
> > > Ralf
>
> > Block[
> > {RowReduce = RowReduce[#1, Method -> "OneStepRowReduction", ##2] &},
> > (* your code here *)
> > ]
>
> simple, doesn't work and results in infinite recursion. I apologize
> for not testing my solution.
>
> Anyway, after thinking about it, I felt that the simple fix would be:
> Block[{RowReduce=System`RowReduce[#1,Method->...,##2]&}, ...]
>
> However, this also results in recursion. Something seems odd: how is
> the blocked RowReduce scoping the fully qualified symbol
> System`RowReduce? (Looking at the Trace, it appears that it is
> dropping the System` context prior to evaluation...)
>
> This works: Block[{Print=System`Print},Print[1]];
> This doesn't: Block[{Print=System`Print[##] &}, Print[1]];
>
> Really odd behavior can be found using the following:
> Let $ContextPath = { ..., "Temp`", ..., "System`", ... }
> Block[{Temp`Print=System`Print[1, ##] &}, Print[2]] will print "12"
> and also cause Print to become shadowed.
>
> I guess the problem boils down to: Why does System`Print simplify to
> Print?
To make my point a bit more clear:
Imagine your $ContextPath does not contain "Temp`" and then let
Temp`f[x___] := {x};
Now, if I evaluate the following code, I get the expected result:
Block[{f=Temp`f[1, ##]&},f[2]] === {1, 2}
Notice: because Temp` is not on the $ContextPath, the fully qualified
symbol is not being truncated from Temp`f to f.
Instead, lets define System`f[x___] := {x};
The default notebook $ContextPath is similar to {..., "System`",
"Global`"};
The same code above, Block[{f=System`f[1,##]&},f[2]], will now become
recursive.
For some reason, it's REMOVING the System` context on System`f during
evaluation, which is causing it to get scoped by Block since
obviously, Block[{f=f[1,##]&},f[1]], will be recursive.
Leonid Shifrin
> Anyway, after thinking about it, I felt that the simple fix would be:
> Block[{RowReduce=System`RowReduce[#1,Method->...,##2]&}, ...]
>
In[107]:= Print === System`Print
Out[107]= True
(I ran this code before running your example with Temp`Print, after which
Print got shadowed and this gave False).
Since Block scopes dynamically, it obeys the same rules. The scoped symbol
is the one currently first on the $ContextPath (if it exists in the symbol
table), while the value it is assigned during the initialization in Block
can be anything, including the symbol itself. My guess is that dropping the
fully qualified name in the Trace is just the usual output formatting:
behind the scenes we always deal with System`RowReduce (or whatever our
symbol is). In particular:
In[108]:= Block[{RowReduce},
Context[RowReduce]]
Out[108]= "System`"
> However, this also results in recursion. Something seems odd: how is
> the blocked RowReduce scoping the fully qualified symbol
> System`RowReduce? (Looking at the Trace, it appears that it is
> dropping the System` context prior to evaluation...)
>
The statement Block[{x=x}, body] seems to make sense only if x has a global
OwnValue, otherwise (if it has DownValues or other ...Values instead) it
seems idle to me - that is, equivalent to just Block[{x}, body]. So, for the
purposes of Block Print and System`Print are identical - that is, the codes
Block[{Print = System`Print}, Print[1]];
Block[{System`Print = System`Print}, Print[1]];
Block[{Print = Print}, Print[1]];
Block[{Print}, Print[1]];
Block[{System`Print}, Print[1]];
are all equivalent (assuming you did not shadow System`Print by importing
some context with another Print). The printing happens not inside the Block
anyway (since inside the Block Print forgets what it is), but the moment we
leave it. Proof:
In[109]:=
ClearAll[f];
f[Unevaluated[Print[x_]]] := {"Value: ", x};
In[111]:= Block[{Print = System`Print}, f[Print[1]]]
Out[111]= {"Value: ", 1}
Since <f> does not hold its arguments, Print[1] would evaluate if it Print
"knew what to do", and the rule in <f> would not match, just as it happens
below, without the Block:
In[112]:= f[Print[1]]
During evaluation of In[112]:= 1
Out[112]= f[Null]
>
> This works: Block[{Print=System`Print},Print[1]];
> This doesn't: Block[{Print=System`Print[##] &}, Print[1]];
>
This has probably nothing to do with Block specifically, and can be modeled
in a simpler setting.
Here we model the code <Block[{Print = Print}, Print[1]]>
In[113]:=
Clear[f];
f = f;
f[1]
Out[115]= f[1]
and here the code <Block[{Print = Print[##] &}, Print[1]]>
In[116]:= Clear[f]
f = f[##] &;
f[1]
During evaluation of In[116]:= $IterationLimit::itlim: Iteration limit of
4096 exceeded. >>
Out[118]= Hold[f[1]]
This suggests that this effect is due to the differences in evaluation in
these two cases, rather than specifically tied to Block. In the second
method, infinite iteration is likely due to the fact that expression is
oscillating between the forms f[1] and f[##]&[1]: after each
parameter-passing stage, evaluator gets a new expression (f[1] instead of
f[##]&[1]), and since it has changed, evaluator re-evaluates it, which again
results in f[##]&[1].
>
> Really odd behavior can be found using the following:
> Let $ContextPath = { ..., "Temp`", ..., "System`", ... }
> Block[{Temp`Print=System`Print[1, ##] &}, Print[2]] will print "12"
> and also cause Print to become shadowed.
>
Indeed, odd enough. If a symbol did not exist in some context, but we decide
to use it in Block, I'd expect Block to clean up, namely return everything
to the way it was before Block has been called. In particular, it should
have removed this symbol from the symbol table at the end, so that there
would be no shadowing after Block has finished. The question is whether this
is a bug or a feature (intended design decision) - I have no idea alas.
Regards,
Leonid
Raffy
> Hi,
>
> > Anyway, after thinking about it, I felt that the simple fix would be:
> > Block[{RowReduce=System`RowReduce[#1,Method->...,##2]&}, ...]
>
> In[107]:= Print === System`Print
>
> Out[107]= True
>
> (I ran this code before running your example with Temp`Print, after which
> Print got shadowed and this gave False).
>
l
> is the one currently first on the $ContextPath (if it exists in the symbo=
l
> table), while the value it is assigned during the initialization in Block
g the
> fully qualified name in the Trace is just the usual output formatting:
> behind the scenes we always deal with System`RowReduce (or whatever our
> symbol is). In particular:
>
> In[108]:= Block[{RowReduce},
> Context[RowReduce]]
>
> Out[108]= "System`"
>
> > However, this also results in recursion. Something seems odd: how is
> > the blocked RowReduce scoping the fully qualified symbol
> > System`RowReduce? (Looking at the Trace, it appears that it is
> > dropping the System` context prior to evaluation...)
>
obal
> OwnValue, otherwise (if it has DownValues or other ...Values instead) it
the
> purposes of Block Print and System`Print are identical - that is, the cod=
es
>
> Block[{Print = System`Print}, Print[1]];
> Block[{System`Print = System`Print}, Print[1]];
> Block[{Print = Print}, Print[1]];
> Block[{Print}, Print[1]];
> Block[{System`Print}, Print[1]];
>
> are all equivalent (assuming you did not shadow System`Print by importing
ck
> anyway (since inside the Block Print forgets what it is), but the moment =
we
> leave it. Proof:
>
> In[109]:=
> ClearAll[f];
> f[Unevaluated[Print[x_]]] := {"Value: ", x};
>
> In[111]:= Block[{Print = System`Print}, f[Print[1]]]
>
> Out[111]= {"Value: ", 1}
>
rint
> "knew what to do", and the rule in <f> would not match, just as it happen=
s
> below, without the Block:
>
> In[112]:= f[Print[1]]
>
> During evaluation of In[112]:= 1
>
> Out[112]= f[Null]
>
>
>
> > This works: Block[{Print=System`Print},Print[1]];
> > This doesn't: Block[{Print=System`Print[##] &}, Print[1]];
>
ed
> in a simpler setting.
>
> Here we model the code <Block[{Print = Print}, Print[1]]>
>
> In[113]:=
> Clear[f];
> f = f;
> f[1]
>
> Out[115]= f[1]
>
> and here the code <Block[{Print = Print[##] &}, Print[1]]>
>
> In[116]:= Clear[f]
> f = f[##] &;
> f[1]
>
of
> 4096 exceeded. >>
>
> Out[118]= Hold[f[1]]
>
in
> these two cases, rather than specifically tied to Block. In the second
> method, infinite iteration is likely due to the fact that expression is
> oscillating between the forms f[1] and f[##]&[1]: after each
> parameter-passing stage, evaluator gets a new expression (f[1] instead of
ain
> results in f[##]&[1].
>
>
>
> > Really odd behavior can be found using the following:
> > Let $ContextPath = { ..., "Temp`", ..., "System`", ... }
> > Block[{Temp`Print=System`Print[1, ##] &}, Print[2]] will print "12"
> > and also cause Print to become shadowed.
>
ide
> to use it in Block, I'd expect Block to clean up, namely return everythin=
g
> to the way it was before Block has been called. In particular, it should
> have removed this symbol from the symbol table at the end, so that there
his
> is a bug or a feature (intended design decision) - I have no idea alas.
>
> Regards,
> Leonid
>
>
>
>
>
> > I guess the problem boils down to: Why does System`Print simplify to
> > Print?
Leonid thanks for all the input. However, not to beat a dead horse,
I'd like make another point.
I thought Block[ {x = ...}, body ] was the equivalent of:
Block$1234`x = ...
$ContextPath = Prepend["Block$1234`", $ContextPath];
body
$ContextPath = Rest[$ContextPath];
Remove["Block$1234`*"];
(which would be essentially how dynamic scoping in general is
performed: you pushing a new resolver on your lookup stack.)
That way, if body was, Print[x + 1], x gets resolved to Block$1234`x
and prints 2.
Or, with my example from before:
Block$1234`f = System`f[1, ##]&;
$ContextPath = Prepend["Block$1234`", $ContextPath];
Print[f[2]];
$ContextPath = Rest[$ContextPath];
Remove["Block$1234`*"];
Where f[2] => Block$1234`f[2] => System`f[1,2]
But it appears that Block[ {x = ...}, body ] is instead figuring out
which long variable it's scoping based on the current context and then
blocking that.
While they gives a similar effects, it seems the latter is far less
useful, because the programmer loses the ability to reference a symbol
with a fully known context path. (It also seems like you could create
a really nasty example of nested Blocks with Context changes but I
can't think of it right now.)
It's good that I now know Block[] is not doing what I expected, I just
wished it performed like my first example. This would give the
programmer the ability to "unblock" by just using the long symbol
name.
Leonid Shifrin
Instead, lets define System`f[x___] := {x};
>
> The default notebook $ContextPath is similar to {..., "System`",
> "Global`"};
>
> The same code above, Block[{f=System`f[1,##]&},f[2]], will now become
> recursive.
>
> For some reason, it's REMOVING the System` context on System`f during
> evaluation, which is causing it to get scoped by Block since
> obviously, Block[{f=f[1,##]&},f[1]], will be recursive.
>
No, it is not removing anything. What's happening is different. Your code
above is completely equivalent to
Block[{System`f=System`f[1,##]&},System`f[2]], hence the recursion. Look:
System`f[x___] := {x};
In[142]:= Block[{f}, Context[f]]
Out[142]= "System`"
(I assumed that <f> was not defined before in Global` or elsewhere on the
$ContextPath).
So, the point is not that some context is "removed" on the r.h.s of your
variable declaration in Block (there is no such operation as "removing the
context", by the way - such a thing would not make sense, since any symbol
is in some context. My understanding is that Mathematica internally never
works with "short names" - short names exist only as an output formatting
for our convenience).
What happens is that once <f> is in some context foo` which is on the
$ContextPath (and first to contain <f>), then Block[{f=something},body] is
equivalent to Block[{foo`f = something}, body]. Moreover, any appearance of
fully qualified foo`f will be replaced according to our instruction in the
declaration of Block, even if a short form (f) was used there:
In[143]:=
Block[{f = System`g},
System`f[2]]
Out[143]= g[2]
since f and foo`f are referring to the same symbol, anywhere inside Block.
In a way, this is the essence of dynamic scoping - it works with existing
symbols (when they exist).
Hope this helps.
Regards,
Leonid
Leonid Shifrin
Thanks for your input as well.
I also think that the alternative you mentioned would be quite useful.
Actually, my wish to have an Unblock operation comes from the same desire
to be able to access "previous" values of a symbol, perhaps by fully
qualified symbols inside the Block, or perhaps by some other means.
Regards,
Leonid