Re: Re: locally changing Options
- To: mathgroup at smc.vnet.net
- Subject: [mg108304] Re: [mg108293] Re: [mg108224] locally changing Options
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Sat, 13 Mar 2010 07:56:08 -0500 (EST)
- References: <5310030.1268308256178.JavaMail.root@n11>
Hi David, 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 > > djmpark at comcast.net > > http://home.comcast.net/~djmpark <http://home.comcast.net/%7Edjmpark>/ > > > > > > > > *From:* Leonid Shifrin [mailto:lshifr at 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 know= s, > 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 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= ark at comcast.net" target="_blank">djmpark at 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:lshifr at gmail.com" target="_blank">lshifr at 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:djmpark at comcast.net" target="_blank">djmpark at 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:djmpark at comcast.net" target="_blank">djmpark at 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:hemmecke at gmail.com" target="_bla= nk">hemmecke at 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--