When you look at modern scientific journals you will find that in the majority of papers (some of) the results are presented in graphical form, from a simple black-and-white X-Y plot to sophisticated multicolor 3D-plots.

The data that are graphed come from various origins, like filled-out surveys, output of detectors, or mathematical programs. If the data are gathererd or produced by a commercial computer program, the developers of that program will try to supply graphing capabilities within the program. Keeping users tied to a program is of high commercial value. So Microsoft’s programs Word and Excel supply plotting facilities, although the capability is so rudimentary that it does not deserve the name.

Plots produced by Mathematica
More sophisticated graphing facilities are supplied by the mathematical programs like Mathematica, Maple and MathCad. Not surprising a major part of the developers of these mathematical programs seem to have a degree in mathematics. And the results are impressive: Mathematica is of staggering high mathematical quality. The disadvantage of being developed by scientists that do not care much about communication is that the presentation quality of the plots from the mathematical programs is from poor to horrible. With a few exceptions, like Ian Stewart, mathematicians are notoriously bad in communicating their results to non-mathematicians. Natural scientists like chemists are better in this respect. The result is that the plots produced are of terrible quality. The plots generated by Mathematica could be used by eye doctors to check the eyes of their patients.

Always high quality
When it comes to publishing your results in a journal you often have to rely on more specialized plotting programs like Origin or Sigmaplot. In my environment the choice is Origin. I think the transition from poor plots to high-quality plots with large font sizes, thick lines, properly labeled axes, full legends etc., should not be postponed to the time of publishing. Also in the communication between scientists and group members high quality of graphs improves the level of scientific discussions and results.

So why not use Origin for all the daily plots? There are a number of problems. The default settings of fonts, line thicknesses, colors etc., are always wrong. Furthermore changing the standard options is awkward. Delivering high-quality plots is time consuming. As a result I am often confronted in my group with poor-quality graphs, produced by Origin. All because the developers of this program have not communicated enough with scientists. Out of the many feature requests I could come up with I will present here two feature requests that could easily be implemented and would make the use of plotting programs much easier.

Feature request 1: comment lines in data files
You will have your data in a database or in some file, like a simple ascii file or comma-separated list or a sql file. While plotting your data you often end up in a cycle of operations: (i) you save a file with your new data, (ii) import this file into your plotting program, (iii) generate your plot and on the basis of this plot you regenerate a slightly modified data file, and so on. In my case it happens that I have typically tens and tens of those cycles until I am satisfied with the results.

I will discuss the simple case of a X-Y plot. You will need a set of data-pairs. If you save such a set of pairs with the comma and linefeed as the separators, any importing wizard in the plotting program will be able to read and interpret this file. If you supply in the first line (record) the labels for X and Y the importing facility will even recognize these headings. So what is the problem? After a couple of years you will be left with hundreds of these data files and you have no idea what they represent. Because in addition to the X,Y variables the plot will be characterized by a set of additional parameters, like temperature, or frequency, of pH, or whatever. You would like to have these data in the file as well. The advantage is that you can use these additional paremeters for the legend. And later, when you reread the file, all these additional parameters will help you to understand what is actually in the file. So how do you put these addtional data in your data file? You could put them in front of the list of pairs. The problem now is that importer of the plotting program does not recognize the file automatically. You will have to tell the program continuously – that is at each cycle –  to skip a number of lines. This slows down plotting cycles considerably and is very irritatable.

The solution can be found in any computer language: a comment line. In Unix lines that start with ” #”,  in Java with “;”  and in C++  with “”//” are interpreted as comment lines that have to be skipped. Whatever the plotting software developers introduce as comment indicator – I could not care less – but introducing it it would help us a lot. The result will be the data file will be automatically recognized by the importer of the plotting program, whatever information is in the comment lines, and the file can be retrieved and interpreted by the user, even after years and years.

Feature request 2: Automatic reload
All modern operating systems use file mappings. That means that when a file is opened and read its content is hold in (physical or virtual) memory. If the developers are smart they do not lock the physical file on disk. The advantage of this not-locked file is that the file on disk can be changed by another program. To prevent mishaps the program developer should check when writing the file back to disk whether or not the file on disk was changed by another program. If the file on disk was changed it should notify the user what to do: reload the new file into memory or overwrite the changed file on disk with the map in memory. Any good program allows the setting of this “write or reload” to be done automatically by setting an option of the program. A computer program developer will typically use several different editor programs at the same time and she would like these programs to work with the newest version of the file automatically. Programs as CodeWright and SlickEdit supply this very handy feature.

I would be very happy if the plotting programs would allow for an option of automatic reload if it discovers that the data file that is the source of the data to be plotted, has changed. In this way we have shortened the plotting cycle considerably: (i) you run the program that will output new data and (ii) you look at the new plot, without any extra mouse clicks or keyboard input, becuase the import wizeard has automatically reloaded the new data file and has automatically updated the plots.

Follow