|
From: Daniel J S. <dan...@ie...> - 2012-05-16 17:44:35
|
On 05/16/2012 11:50 AM, Allin Cottrell wrote: > On Wed, 16 May 2012, Daniel J Sebald wrote: > >> Perhaps there should be a mode switch, "use the same data" or "don't >> reread". But I'm not sure how crucial that is. > > Just a notion, but what if gnuplot's syntax permitted defining a matrix > (either "inline" with some nice, simple syntax or by reading from a > file), and you could then say something like > > plot matrix "foo" using ... > > as many times as you wanted, using whichever columns? Well, that's a paradigm change as far as programming because the whole plot command would need to be processed to figure out what columns are required for _all_ plots not just the current one. That also expands the number of possible storage elements creates difficult programming in this design. Currently, the data file could be (exaggerating) 1000 columns wide but for any given plot gnuplot selects and stores only the few columns of data it needs for individual plots (say column 1, column 50 and column 51 on the first plot). It does the same for the next plot, but it rereads the file and might select a different few columns (say column 1, column 120, column 121). Attempting an explanation, gnuplot has been programmed in such a way as to not "look ahead" at what is to come. Changing to a system that needs to "look ahead" for plots that are to come really creates challenges internally. gnuplot started in an era in which memory wasn't so readily available, but at the same time I think it should probably remain close to the parsimonious paradigm as possible. In my opinion, software generally has become a little too bloated. I did write a patch a while back that stored the raw data, sort of bucking that paradigm, but that was storing just the columns of data an individual plot uses, not the whole possible data file, i.e., no "look ahead" but instead "store what has been used". Dan |