13
$\begingroup$

Bug introduced in 11.1 or earlier and persisting through 11.3.0 or later

CASE:4024964

Here's a weird one. Starting with a fresh kernel, the first time I plot a function of \[FormalX], I get an error and a blank graph:

Plot[\[FormalX], {\[FormalX], 0, 1}]
(* SetDelayed::wrsym: Symbol \[FormalX] is Protected. *)

Mathematica graphics

Then if I rerun the same code, it works fine:

Plot[\[FormalX], {\[FormalX], 0, 1}]

Mathematica graphics

I've tried a few other formal variables. Plotting with \[FormalY] and \[FormalZ] both work from the start, and even prevent the same error with \[FormalX] when used afterwards.

Does anyone else have this problem? I'm using Mathematica 11.2 on MacOS 10.13.3. Any idea what the cause is?

Addendum (June 3, 2018)

I've run into the same problem with ContourPlot. As per Szabolcs' comment, I had fixed my problem with Plot by placing Plot[0, {x, 0, 1}]; at the top of the package I'm writing to be silently run when loaded. However this does not prevent the same error from occuring with ContourPlot. However, adding ContourPlot[0,{x,0,1},{y,0,1}]; does fix it.

|improve this question
$\endgroup$
  • 1
    $\begingroup$ I can reproduce this behavior with V11.1.1 running of OS X 10.10.5. Certainly looks like a bug to me. $\endgroup$ – m_goldberg Mar 5 '18 at 2:12
  • 2
    $\begingroup$ I can reproduce the error on 11.2.0 for Mac OS X 10.13.3 on a fresh kernel. $\endgroup$ – QuantumDot Mar 5 '18 at 3:35
  • 3
    $\begingroup$ Related: chat.stackexchange.com/transcript/message/43189163#43189163, chat.stackexchange.com/transcript/message/43201818#43201818 $\endgroup$ – Michael E2 Mar 5 '18 at 4:02
  • 4
    $\begingroup$ Yep. I agree it's a bug. Executing almost any(?) plot command seems to fix it. It makes me wonder what they mean in the docs that formal symbols are "Used to represent a formal parameter that will never be assigned a value" -- except in Plot, Table, Do, etc. (These functions can set a value to protected symbol, even a locked one; Block cannot if the symbol is locked, though. $\endgroup$ – Michael E2 Mar 5 '18 at 13:07
  • 3
    $\begingroup$ My suspicion is that when Plot runs for the first time, it triggers the auto-loading of the same file that sets FormalX to be Protected. Evaluating Plot alone is not enough to trigger it. It is necessary to use proper syntax, e.g. Plot[x,{x,0,1}]. Thus it is not the loading of the Plot symbol itself that triggers this. It's something else used internally by Plot. $\endgroup$ – Szabolcs Mar 6 '18 at 14:46
5
$\begingroup$

I'll expand a bit on the comments by @Szabolcs which are essentially correct.

Various functionality implemented in top-level is typically autoloaded on first use from MX files (written by DumpSave). A feature of MX files is that when they are read back, all definitions and attributes of the saved symbols are restored.

The actual bug is caused by the DataWrappers.mx file unintentionally capturing the \[FormalX] symbol's Protected attribute (the symbol itself is normally defined in a different place).

When Plot is first used, its internal dependency on EventData triggers autoloading of DataWrappers.mx which causes \[FormalX] to become Protected again, even though its attributes have been temporarily unset by localizing.

As an illustration (using Block instead of Internal`LocalizedBlock for simplicity):

Block[{\[FormalX]}, {Attributes[\[FormalX]], \[FormalX] = 1}]

(* {{}, 1} *)

Block[{\[FormalX]}, EventData; {Attributes[\[FormalX]], \[FormalX] = 1}]

Set::wrsym: Symbol \[FormalX] is Protected.

(* {{Protected}, 1} *)

Block[{\[FormalX]}, EventData; {Attributes[\[FormalX]], \[FormalX] = 1}]

(* {{}, 1} *)

Note there was no longer a message on the second evaluation of the same input; that is because autoloading happens only once, at the first evaluation of EventData in a kernel session.

|improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.