Problem introduced in Version 11.0, reported as CASE:3708213, fixed in Version 11.0.1.

An alternative solution to 125561 is

s = p /. First@Solve[q == (0.0238849 p + 0.903548 p^1.86), p];

a Root function with LeafCount of 458. It can be plotted without difficulty by

Plot[s, {q, 0, 1}, PerformanceGoal -> "Speed"]

enter image description here

ListLinePlot[Table[s, {q, 0, 1, .001}], DataRange -> {0, 1}]

produces almost the same plot, omitting a few points at very small q, where s evaluates to Indeterminate; e.g.,

Position[Table[s, {q, 0, 1, .0001}], Indeterminate]
(* {{6}, {7}, {8}, {9}, {11}, {16}, {18}, {19}, {20}, {21}, {22}, {23}, {25}, {27}} *)

On the other hand,

Plot[s, {q, 0, 1}, PerformanceGoal -> "Quality"]

runs about 20 minutes, returning a blank chart. The much less demanding

Plot[s, {q, .9, 1}, PlotPoints -> 10, MaxRecursion -> 0]

does the same. Why?


Feyre observed in a comment below that Plot with PerformanceGoal -> "Quality" ran fine on Ver 10.4, which I just confirmed with Ver 10.4.1. Perhaps, Ver 11.0, which I used above, has introduced a bug.

  • 1
    $\begingroup$ Failed to reproduce Debian Stable,10.4, all run fine. $\endgroup$ – Feyre Sep 5 '16 at 19:42
  • $\begingroup$ @Feyre Many thanks. I should have thought to check this behavior for 10.4.1, for which it works fine. But, not 11.0! Bug, perhaps. $\endgroup$ – bbgodfrey Sep 5 '16 at 19:53
  • 1
    $\begingroup$ Very strange: Fast: Plot[(foo = 0; s), {q, 0, 1}, PlotPoints -> 2, MaxRecursion -> 0, PerformanceGoal -> "Quality"]. Slow: Plot[(s), {q, 0, 1}, PlotPoints -> 2, MaxRecursion -> 0(*, PerformanceGoal -> "Quality"*)], with or without PerformanceGoal -> "Quality"; it appears to hang before the function is evaluated (use foo++ instead of foo = 0 or EvaluationMonitor), although it could have started to evaluate it. $\endgroup$ – Michael E2 Sep 5 '16 at 21:05
  • $\begingroup$ @MichaelE2 Reap[Plot[(s), {q, .9, 1}, PlotPoints -> 10, MaxRecursion -> 0, EvaluationMonitor :> Sow[s]]] takes 20 minutes to Sow 10 evaluations of s and yields a plot with no curve. Adding PerformanceGoal -> "Speed" reduces runtime to a negligible amount, Sows the same values, and gives a correct curve. $\endgroup$ – bbgodfrey Sep 5 '16 at 22:41
  • 1
    $\begingroup$ 20+ min. to first evaluation, then all done in less than a second: i.stack.imgur.com/hzO3r.png $\endgroup$ – Michael E2 Sep 6 '16 at 1:22

One part of the problem lies in the computation of Exclusions. Another part is in the use of the computed exclusion criterion in the construction of the plot; I do not understand this part fully. The connection with PerformanceGoal is found in the docs for Exclusions:

Exclusions -> Automatic is effectively equivalent to Exclusions -> All if $PerformanceGoal is "Quality", and to Exclusions -> None otherwise.

First, to compute the exclusions of Root[f, k], which may have discontinuities at branch points, Plot essentially computes

Resultant[f[x], f'[x], x]

For the Root in s, we get, after about 20 minutes or so,

resultant = Resultant[s[[1, 1]], D[s[[1, 1]], #], #];
Short[resultant, 5]

Mathematica graphics

That's kind of a whopper, both in degree and in coefficients. You can see this in the exclusion computed, if you're willing to wait another 20 min., with this:

Visualization`ExpandExclusions[s, {q}, Automatic] // AbsoluteTiming

Mathematica graphics

So I think this explains the 20 minute wait for the plot.

As for the second part, it seems to me one might expect numerical difficulties. The left-hand side of the resultant does not evaluate to machine-size reals for q between 0.9 and 1, and Plot coordinates have to be (smaller than) machine reals (Plot[$MaxMachineNumber/100000*x, {x, 0, 10}] v. Plot[$MaxMachineNumber/10000*x, {x, 0, 10}]). Perhaps exclusions are computed at machine precision and overflow is treated as Infinity. This is just a guess, though.

Bug or not? I used to think it was, but it seems like an improvement to handling Root objects was added, which has some consequences. On the plus side, Plot does not connect the jumps in a Root[]. It would be nice to be able to control it. There might be a time constraint on computing exclusions, or maximum degree for Root[]. In this case the coefficients of s are greater than $MaxMachineNumber, which could be taken as an indicator to skip computing exclusions.

In any case, I think the standard answer should be to use Exclusions -> None for plotting a complicated Root[] when plotting it takes a long time.

  • $\begingroup$ Thank you for lavishing such careful attention on this question (+1). Although s[[1]] has numerous branch cuts, Root[...,1] shows no evidence of crossing from one branch to another. Also, I computed ss = Series[s, {q, .8, 3}] // Normal, which agreed well with s for q > .5. Mathematica also warned me that the expansion might be on the wrong branch, but it was not. So, although your explanation of why Plot is so slow in this instance seems very plausible, I continue to believe that failure to plot a curve is a bug. $\endgroup$ – bbgodfrey Sep 6 '16 at 19:49
  • 1
    $\begingroup$ @bbgodfrey You're welcome...I'm not saying that branches of s affect the graph; I agree that they do not. I'm saying the issues are (1) that s is a Root object, which entails branch checking, and (2) that the larger-than-machine-real values of the resultant used in checking for branches might overflow yielding an IEEE infinity and might be interpreted as a singularity. The overflow has nothing to do with jumping branches. -- BTW, I got the Resultant[] from this: Trace[TimeConstrained[Plot[s, {q, 0.9, 1}], 0.2], _Resultant, TraceInternal -> True], but it's inconsistent. $\endgroup$ – Michael E2 Sep 6 '16 at 22:54
  • 1
    $\begingroup$ @bbgodfrey Another bit of proof: Block[{Resultant}, Resultant[___] := 1; Plot[s, {q, 0, 1}, PerformanceGoal -> "Quality"]]...just playing... $\endgroup$ – Michael E2 Sep 7 '16 at 2:42

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.