3
$\begingroup$

In this question: Options which require RuleDelayed , an example was given, where the an option has to be given as a RuleDelayed: EvaluationMonitor of NMinimize.

But many other functions use Functions in the same application: take ColorFunction of DensityPlot.

Instead of usage

NMinimize[x^4 - 3 x^2 - x, x, EvaluationMonitor :> Print[x]]

one could perhaps implemented NMinimize as

NMinimize[exp_, x_, ___, OptionsPattern[]] := OptionValue[EvaluationMonitor][x]

Another example in an answer was Path :> $Path which delays the evaluation, but in many applications Automatic is used instead, which then triggers evaluation.

In which applications are RuleDelayed useful for giving options? Are there applications, where the lhs of the option would be a pattern?

I would like to understand the design pattern and good practice behind these advanced features.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
3
$\begingroup$

Short answer is, you can achieve the same with different idioms but some are better in some cases than another. Pick the one that reduces amount of code that you and user need to write because it will probably contribute to experience and robustness.

Options which expect functions

ColorFunction, MeshFunctions etc all are supposed to be functions because the author provides a fixed set of arguments and it is up to the user what to do with them.

Options with :>

Why not a function for EvaluationMonitor? Because, among others, NMinimize can have many different things in its varspec. It can be a symbol, list of symbols, _ ∈ region_, etc.

Either user would have to have parse it MonitorFunction -> myMonitor @* standardizeVarspec or the author would have to waste time to convert any varsepc to e.g. a list of symbols. Not worth the effort if user can just write Print[x].

Options with :> vs symbolic options

The gain in Path :> $Path case, except it obviously delays $Path evaluation, is that the author does not need to write OptionValue[Path] /. Automatic -> $Path etc. Not the major problem but that line can be half of its length. Additionally it is self documenting.

It may be worth it, if the default value ($Path) is simple and there is only one default value (for more you need to switch inside anyway).

If it is not simple it may be a pain to use when user writes a code that plays with that option. This is fine:

... path = If[condition, customPath, $Path]; YourFunction[..., Path -> path] ...

This is not:

... opt = If[condition, customOpt, complexValueOf[YourFunction's, Default->Option] (*made up example*) ]; YourFunction[..., Opt -> opt] ...

So here a symbolic options make more sense:

... opt = If[condition, customOpt, Automatic ]; YourFunction[..., Opt -> opt] ...
Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks for a great answer! You covered almost all of my concerns. How about left side value being a pattern? Does option like Options[myfunc]={f[a_]:>g[a]} have any application examples? It feels very powerful. $\endgroup$ Commented Sep 18, 2018 at 10:24
  • $\begingroup$ @Johu I am not sure how should that work, how would e.g. a call to myfunc look like? And how and what would you like to retrieve the option inside? What pros do you see here? $\endgroup$ Commented Sep 18, 2018 at 11:34
  • $\begingroup$ This was my question :). $\endgroup$ Commented Sep 18, 2018 at 12:33
  • $\begingroup$ @Johu I understood your question as 'where is this feature useful' while I am asking, but what feature? Options[myfunc]={f[a_]:>g[a]} is not enough for me to understand what do you mean.\ $\endgroup$ Commented Sep 18, 2018 at 12:36
  • $\begingroup$ ok. thanks. I will add an extend example to the Q later. $\endgroup$ Commented Sep 18, 2018 at 12:39

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.