3
$\begingroup$

The answer in How to monitor the progress of a plot is not useful in my case.

I am using 

ListLogLogPlot[{Thread[{bigListX, bigList2}], Thread[{ssfPos, PSDPos2}]},
  PlotRange -> All]

The problem is that those lists are really big, around $200 \times 10^6$ points. I would like to see the progress of the plotting. I want Mathematica to tell me "where" it is at the moment.

Improve this question
$\endgroup$
8
  • 3
    $\begingroup$ The title does not match the content, imo. $\endgroup$
    – Kuba
    Commented May 26, 2015 at 9:57
  • 7
    $\begingroup$ In my opinion, it is not reasonable to draw a figure with 200 million points on. Normally, these kind of problem can be represented by sampling the dataset. Drawing 200 million points in a 6 inch by 4 inch square is not a very useful for visualizing your data. $\endgroup$
    – Kattern
    Commented May 26, 2015 at 11:34
  • 2
    $\begingroup$ Moreover, in Plot time is spent on recursion/sampling the domain, here not. Mostly on rendering, it takes a lot due to the sample size. Now you would like to interrupt it at each point and show it somewhere which means you want to plot 200kk plots with sample sizes from 1 to 200kk... $\endgroup$
    – Kuba
    Commented May 26, 2015 at 11:48
  • 1
    $\begingroup$ You might be interested in this $\endgroup$
    – J. M.'s missing motivation ♦
    Commented May 28, 2015 at 0:24
  • 2
    $\begingroup$ @Oleksandr it has been mentioned 48 times so far on this site so it's not too esoteric at this point. $\endgroup$
    – Mr.Wizard
    Commented May 28, 2015 at 1:27

2 Answers 2

Reset to default
4
$\begingroup$

Following Mr. Wizard's suggestions, I'll offer the following comment to the OP's situation in an attempt to summarize the communal wisdom on this point.

The great difficulty in the OP's question is in timing the rendering process, which takes place in the Front End and vastly overshadows the calculation time in the original problem. Unfortunately, there is no (documented/known) way to do that so far.

I also think, however, that the whole point may be moot. If the situation is such that rendering overshadows computation, then one should consider pruning the data set being plotted because it is likely to be too detailed to be meaningfully presented at common resolutions and sizes, as kettern also mentioned.

In this connection, one can make judicious use of the MaxPlotPoints option for the list plotting functions to downsample such a data set automatically (its documentation states that "the total number of points plotted is reduced by combining nearby points"). Oleksandr and Mr. Wizard mentioned it in comments as well.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Marco, I encouraged you to post this and I still believe it is a valid and important point. However in brief testing it seems the situation has changed between versions 7 and 10.1. In version 7 ListPlot evaluates very quickly. In 10.1 it is much slower, greatly surpassing rendering time. I shall explore this tomorrow if I have time. $\endgroup$
    – Mr.Wizard
    Commented May 28, 2015 at 4:19
  • $\begingroup$ @Mr.Wizard No worries: I had not done any testing myself, nor do I have older versions at hand, so I had not noticed. That would be interesting to see, if you get round to it. If it turns out to be a different problem altogether, I can always remove / update my answer. $\endgroup$
    – MarcoB
    Commented May 28, 2015 at 4:35
  • $\begingroup$ It seems that only in certain cases such as multiple data sets is ListPlot generation slow. I posted a new question about it. $\endgroup$
    – Mr.Wizard
    Commented May 29, 2015 at 16:04
  • $\begingroup$ Could you have a look at this question as well^^ ? link $\endgroup$
    – newandlost
    Commented May 31, 2015 at 11:17
-2
$\begingroup$ 
 Monitor[ListLogLogPlot[Table[{n, y = n RandomReal[]}, {n, 1, 10^5}]], 
 ProgressIndicator[y, {1, 10^5}]]
Improve this answer
$\endgroup$
6
  • $\begingroup$ David, this may not work as you intended. The indicator seems to show progress as numbers are generated, but the rendering of those points by the plotting function, which is the part that takes the longest, is not captured. $\endgroup$
    – MarcoB
    Commented May 26, 2015 at 16:33
  • $\begingroup$ @MarcoB Try the new solution. $\endgroup$
    – David G. Stork
    Commented May 26, 2015 at 16:36
  • $\begingroup$ Unfortunately, the progress indicator is now meaningless, since it is literally fed a random value. It will stop at a point indicated by the last random number that was generated, which may be at the beginning, in the middle, or at the end, by random chance. It will then pause there while rendering happens. This behavior may be more clear if you try with an upper limit of 10^6. $\endgroup$
    – MarcoB
    Commented May 26, 2015 at 16:41
  • 3
    $\begingroup$ I think that the great difficulty in this question is timing the rendering process, which vastly overshadows the calculation time in these examples, and in the OP's original problem. I think, however, that the whole point may be moot. If the situation is such that rendering overshadows computation, then one should consider pruning the data set being plotted because it's simply too detailed. $\endgroup$
    – MarcoB
    Commented May 26, 2015 at 16:46
  • $\begingroup$ @MarcoB I think you should make that an answer, because IMHO it is the best one available. I think only an undocumented hook in the Front End that gives a progress monitor on rendering would do any good here. $\endgroup$
    – Mr.Wizard
    Commented May 28, 2015 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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