On 2015-01-13 21:13-0000 Andrew Ross wrote: > > Can I suggest a script which runs all the standard examples, saves as > plmeta files, then re-renders using the psc driver. It would be > illuminating to compare with the direct psc driver and should also > highlight any missing API elements in the buffering.
Good idea! However, this brings up the question of what device should be used for your current diff script and this new addition to it. I ask you to replace -dev psc for such purposes because that device does not support certain modern PLplot capabilities so it produces garbage results for example 24 and several others. So for those examples, our current diff script is simply checking that the garbage is consistent. :-) I recommend -dev svg as the replacement device because it also does not depend on external libraries, it has complete support for all modern PLplot capabilities, and the resulting XML files in the SVG schema are quite readable if you ever need to debug an issue. > I'll see if I can knock something together. Good! > Note Maurice's comments about not completely reproducing the original > device, but again it would be good to quantify that. My feeling from what Maurice said is if you abandon the current low-level -dev plmeta approach and use something higher level (which Phil is apparently going to do), then with care you should be able to get exact reproducibility. My reasoning is for the same input, the internal physical coordinates should always be the same. Therefore, if you are storing those rather than storing some rounded and transformed actual physical coordinates for a device, in principle you should always be able to reproduce results exactly whether a new plmeta step (which stores internal physical coordinates exactly to a file and also reads them back in exactly) is part of the pipeline or not. Once we have exact reproducibility then a test comparing -dev svg results with alternative -dev svg results (determined where plmeta values are written to disk and then read back in again and then expressed with -dev svg) should give exactly the same results. And then running such a test for all our standard examples should make a strong test that the new plmeta approach supports all modern PLplot capabilities. To summarize, I view this as a wonderful opportunity to make what was a neglected part (but really useful part) of PLplot strong. So I am glad that Phil is going to implement a new plmeta approach, and with appropriate tests like described above, we should be able to thoroughly debug the reproducibility and PLplot capability support of that new approach. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
