MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

a technique for options

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:


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
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:






Here is what would happen on the last call if the user chose the
technique in the Mathematica Book:


N::arg: Argument {20} is not of the form {precision, accuracy}.



  • Prev by Date: Re: Re: 1`2 == 1*^-10
  • Next by Date: Re: Re: 1`2 == 1*^-10
  • Previous by thread: Re: draw vertical cylinder with no surface lines
  • Next by thread: Re: a technique for options