Re: Re: a technique for options
- To: mathgroup at smc.vnet.net
- Subject: [mg71729] Re: [mg71635] Re: a technique for options
- From: "Chris Chiasson" <chris at chiasson.name>
- Date: Tue, 28 Nov 2006 06:03:34 -0500 (EST)
- References: <200611251037.FAA15666@smc.vnet.net>
Ingolf,
While that was extremely humorous, I must admit that your rhymes are
also a little scary :-)
On 11/26/06, Ingolf Dahl <ingolf.dahl at telia.com> wrote:
> Hi Daniel and Chris,
> Do you agree that this is a tree?
>
> In[1]:=
> tree = {{{{}, {{}, {}}}, {{}, {}}, {{}, {{}, {}}}}};
>
> It's made out of Options as you can see:
>
> In[2]:=
> OptionQ[tree]
>
> Out[2]:= True
>
> Now you can try ReplaceAll apply
>
> In[3]:= apple /. {tree}
>
> Out[3]:= {{{{apple, {apple, apple}}, {apple, apple}, {apple, {apple,
> apple}}}}}
>
> Then you have apples for your apple pie!
>
> If this you shook, just take a look
> in section 2.5.1 in the book!
>
> Now seriously, I have tried to check the command Plot, which should be a
> typical command with options. It does not seem to matter if you supply
> options as rules, as lists of rules or as nested lists of rules. So probably
> internally in the command the options are extracted essentially in this
> way, with PlotRange as example:
>
> pr = PlotRange /. Flatten[{opts}] /. Options[Plot]
>
> If the list of options is not flattened, ReplaceAll might replace PlotRange
> with a list of replaced or un-replaced values, as in the apple example
> above. But if this method with Flatten is followed also in user-written
> functions, it should be OK to specify the options arguments by
> opts___?OptionQ . Please correct me if I am wrong here, because in that case
> I have to rewrite a lot of functions.
>
> I agree with Chris that the section 2.3.10 should be corrected (Include the
> OptionQ test, and Flatten[{opts}]!)
>
> Best regards
>
> Ingolf Dahl
>
> And by the way, its fun to play,
> and a laugh and an apple keeps the doctor away!
>
> > -----Original Message-----
> > From: dh [mailto:dh at metrohm.ch]
> > Sent: den 25 november 2006 11:37
> > To: mathgroup at smc.vnet.net
> > Subject: [mg71635] Re: a technique for options
> >
> > Hi Chris,
> > there seems to be an misunderstanding. The technique in the
> > book works well, if you feed it the requested input. If the
> > input is wrong, it obvioulsy does not work.
> > Consider ____, this means zero or more arguments. If it is
> > used as explained in the book, it means zero or more Rules
> > and not "list of rules".
> > Unfortunately OptionQ gives True if you feed it a rule or a
> > list of rules, leading to the error message you saw.
> > Therefore, to check if you really have rules, you could e.g.
> > use opts___?(Head[#]==Rule&) Daniel
> >
> > Chris Chiasson wrote:
> > > I noticed this a few months ago, but I am just getting around to
> > > programming this way, and I'd like to share it with you:
> > >
> > > OptionQ evaluates to True for an option or a list of
> > options. A lot of
> > > built in functions can handle their options given as lists:
> > >
> > > Plot[x,{x,0,1},{PlotStyle->Blue}]
> > >
> > > However, users (myself included), seem to be writing code
> > that ignores
> > > this aspect of option handling. I blame this ( like all my other
> > > Mathematica failings :-] ) squarely on the documentation,
> > specifically
> > > section 2.3.10.
> > >
> > > BTW, I just noticed that OptionQ, like StringQ, does not
> > have a help
> > > browser entry.
> > >
> > > Here is an example from that section on writing functions
> > that take options:
> > >
> > > -----------------------------------------------------------------
> > > f[x_, opts___] := value
> > > a typical definition for a function with zero or more named
> > optional
> > > arguments name/.{opts}/.Options[f] replacements used to get
> > the value
> > > of a named optional argument in the body of the function
> > > -----------------------------------------------------------------
> > >
> > > There are two things "wrong" with the example. The first, and
> > > non-serious, problem is that the named pattern opts isn't
> > checked with
> > > OptionQ. The second, and more serious, problem is that the
> > result of
> > > name/.{opts}/.Options[f] will likely be different if the
> > user feeds an
> > > option list to the function instead of the expected option sequence.
> > >
> > > People may feel that it is a waste of time to support such
> > a calling
> > > convention, but it is actually rather easy to do robustly, AFAIK.
> > >
> > > The technique involves the exploitation of Flatten (and the
> > fact that
> > > rules aren't lists)... Here is an example:
> > >
> > > Options[f]={Precision->40};
> > > f[x_,callOpts___?OptionQ]:=
> > > With[{opts=Flatten[{callOpts,Options[f]}]},N[x,Precision/.opts]]
> > >
> > > f[5]
> > > f[5,Precision->10]
> > > f[5,{Precision->20}]
> > >
> > > 5.000000000000000000000000000000000000000
> > >
> > > 5.000000000
> > >
> > > 5.0000000000000000000
> > >
> > > Here is what would happen on the last call if the user chose the
> > > technique in the Mathematica Book:
> > >
> > > System`Dump`$MessagesInHelpBrowserAreKnown=False;
> > > N[5,Precision/.{{Precision->20}}/.Options@f]
> > >
> > > N::arg: Argument {20} is not of the form {precision, accuracy}.
> > >
> > > N[5,{20}]
> > >
> >
> >
>
>
>
--
http://chris.chiasson.name/
- References:
- Re: a technique for options
- From: dh <dh@metrohm.ch>
- Re: a technique for options