Ooops! Thanks. Is this an error, or a new policy?

Quiz: For some reason the autograder does not work for me.

Thank you. I did not get it, but it is already discussed above. :( :)

Hi Abrita,

I cannot post my answer here so I created a cloud notebook with my answer and shared it with you. Check your gMail email.

Thanks, Rohit

Hi Rohit, I can confirm autograder is accepting the right answer for #8.

Could you please post the link to the quiz.

Hi John,

Looking at your attached notebook: if you don't know what variables are going to be in expr, then localising with Block seems fine to me.

That said... if you're localising particular variables (say, x and y), that suggests to me that you do know what variables are going to be in expr...? If that's the case, I would define it as expr[x_, y_] := Plus[x, y]. Then, if you define f as f[x_, y_] := expr[x, y], you can do without the Block.

In other words:

ClearAll[f1, f2, expr1, expr2, x, y];
x = 1; y = 2;

(* What you're doing now: *)
expr1 := Plus[x, y];
Block[{x, y}, f1[x_, y_] := Evaluate[expr1]]
f1[3, 4]

(* What I would do instead, if possible: *)
expr2[x_, y_] := Plus[x, y];
f2[x_, y_] := expr2[x, y];
f2[3, 4]

Side note: have you used \[FormalX] and \[FormalY] before? They can be handy for avoiding conflicts with global variables.

The answer to quiz question #8 that the autograder accepts as correct looks incorrect to me. Can someone please check? Thanks!

Hello Daniel,

On second sober thought (less foggy mind this morning), Looking again at the Alternatives documentation it does say ... represents any of the p's , which with a little extra thought includes that a single p be tested.

So up to you, but I'd now be happy that the lesson workbook stay as is.

Thanks again. John

Hi John,

I don't quite understand your first point about parsing... Could you clarify what you mean by this?

When an options pattern is defined as options:OptionsPattern[], callling options will return a Sequence. Try evaluating the following to see what I mean:

Options[f] = {"a" -> 1, "b" -> 2};
f[options : OptionsPattern[]] := options;
f["a" -> 3, "b" -> 4]

I therefore generally wrap options in a List to make it easier to deal with. In fact, the functions FreeQ and DeleteCases will not work if they are fed a (multi-element) sequence in the first argument.

I tested for RoundingRadius instead of "RoundingRadius" because the Framed function accepts the option name without quotes. (It also accepts it with quotes.)

You are correct in both of your last points! Using Alternatives inside DeleteCases isn't necessary when there is only one case to delete, and the entire statement could be replaced with options because the rounding radius option is being taken care of by the Condition. Thanks for pointing these out – I will remove them from the notebook.

I'd like some help to understand the statements in Wednesday's lesson, which I'll copy here and hope you can identify back to the lesson workbook.

(* When no explicit RoundingRadius is given, scale it with the \
FrameMargin: *)
frameText[text_String, options : OptionsPattern[]] /; 
   FreeQ[{options}, RoundingRadius] := Framed[
   Text[text],
   RoundingRadius -> OptionValue[FrameMargins]/2,
   Sequence @@ 
    DeleteCases[{options}, Alternatives[RoundingRadius -> _]]
   ];

I don't understand how to inquire on the value of text and options when the function call is parsed ie. frameText[text_String, options : OptionsPattern[]] . Perhaps first question is whether once can inquire what would be assigned to text and to options?

In any case the programmer placed option is a List ie {options} inside function calls to FreeQ and DeleteCases. They also knew it was sufficient to ask test {options} with RoundingRadius instead of "RoundingRadius" in FreeQ. which isn't entirely obvious from the Help Documentation of FreeQ.

I'm also not entirely sure how to interpret Alternatives[RoundingRadius -> _ used inside the call to DeleteCases. The documentation of Alternatives describes usage with more than one alternative to choose from so Alternative[arg] is vague. Lastly my understanding of the syntax RoundingRadius->_ would require that RoundingRadius->val was assigned which FreeQ would have screen out as False so would this whole statement not be redundant and so never called upon?

Thanks.

This is a reminder that Daily Study Group: Writing a Wolfram Language Function begins on Monday, September 12. It runs for just one week. Register today: https://wolfr.am/16funYdYF