| Thanks, Dan and Mike, for your very helpful comments.
I am using the Mac Pro workstation with 12 cores on OS X 10.7.3.
Yes, I better do some preprocessing, or, maybe, since 176259 points were in time (of 100 particles at each time instant), I could plot different segments of it in different windows or some such thing. We generally don't think about such restrictions and simply dump all the data onto the plot routine expecting it to show all. I should devote some time to understanding what the exact limitations are and then plot.
I wonder what filtering Matlab is using…
Best,
KM.
Dr. Krishna Mohan, T. R
CSIR Centre for Mathematical Modelling and Computer Simulation (C-MMACS)
NAL WTC Road
Bangalore 560 037, India
Tel: +91-80-2505 1927
Fax: +91-80-2522 0392
On 11-May-2012, at 12:33 PM, Daniel J Sebald wrote: On 05/10/2012 12:13 PM, Michael D Godfrey wrote: On 05/10/2012 06:16 AM, Dr. Krishna Mohan, T. R wrote:
But, pray, why this restriction in Octave/gnuplot? Matlab has no such
problems.
I have found that Matlab does have problems with very large arrays.
They are just different from those in Octave. My suspicion is that there
is code somewhere in the paths that fails to use appropriate indexing,
but this is pure speculation. Both systems should be improved since
vary large arrays are increasingly common. However, this is not
a simple matter since some of the problems may be in places like
OpenGL, gnuplot, etc... (Matlab uses OpenGL, but does some rescaling
to make it work for reals.)
mdg
Krishna, To have versions of Octave on multiple platforms requires a lot of open source utilities. Although the flexibility is there, there may be some limitations because of memory consumption or what have you. (That is a large number of pixels in your example.) There could be some overhead that might not exist if one had a graphics system designed particularly for the application. In addition, support for Mac and Windows may not be as robust as for Linux because a lot of the developers have concentrated on core functionality rather than graphics up to this point. Perhaps if you give some information about your platform I could inquire with the gnuplot list as to why the limitations. Aside from making the plot visible, you still might want to consider pre-processing your data before plotting. The reason is that any display method having a resolution smaller than that of the data is going to have to manipulate the data in some way first. By doing that pre-processing yourself, you know what is happening. With myriad platforms and output formats you can't be quite sure about any one method unless some documentation indicates the algorithm it uses. For example, this instruction that Ben suggested as a test: a = s(1:100:k2,1:100); is one susceptible to aliasing because it is decimating without lowpass filtering. An example of a lowpass filter would be to simple take the average of the block of 100 samples rather than using every 100th sample. There might be other things like imresize that you could use. Dan
|