On 2015-01-10 13:57-0600 Maurice LeBrun wrote: > Both the endianness and IEEE float issues are dealt with in a portable way by > the functions in src/pdfutils.c. Neither integers or floating point are > dependent on the native architecture, making the metafiles 100% portable. > > 1. Endianness is "little", by fiat, implemented by shifts & masks. > 2. Floating point is IEEE, by fiat, implemented as per the spec. At the time > some architectures didn't use IEEE floats (e.g. Cray) and there wasn't much > need for f.p. output for a device driver, so speed wasn't an issue.
Hi Maurice: Thanks for joining the discussion. I think the above treatment of endianness and float types is fine. Therefore, the rewrite (assuming it is binary rather than SVG) should copy or use directly the relevant code in src/pdfutils.c concerning endianness and floating-point representation. > Design issues include: > - As mentioned, it fell out of active use so as device driver capability > grew, plmeta became unable to fully reproduce the observed output. > - The physical device coordinate space was a limiting factor, say for later > zooms. The exact definition of what constitutes a physical device coordinate needs to be discussed. Our documentation does not define physical device coordinates in doc/docbook/src/* (a likely deficiency of that documentation). In particular, plbuf (mentioned as useful for the rewrite) appears to use shorts to represent positions, and positions are also represented as shorts in the code in src/*.c for libplplot. I define those (and presumably what plbuf uses) as "internal" physical coordinates which device drivers other than plbuf typically scale into double precision values to represent "real" physical coordinates. I assume for the purposes of the further discussion that you meant "internal" physical device coordinates but please confirm that (or take the rest of what I say with a grain of salt if that assumption is incorrect). The problem with using shorts to represent internal physical coordinates is those 16-bits are not really enough. There are problems with zoom (as mentioned by you above). Also, there are problems for the unzoomed case. For example, we had to fight for years to desensitize our standard examples to floating point rounding issues. The problem was we needed to avoid certain magic numbers where our input PLFLT world coordinates or normalized device coordinates (say for any labels or tick marks) would transform to a position almost exactly between two integers in internal physical coordinates so that a very slight floating-point rounding error in calculated positions would propagate to a substantial visible change in the resulting plot. Because of these known floating-point rounding sensitivity issues, I am also convinced (although I cannot tell for sure because I am used to the current look of PLplot results) that our plots would likely look much smoother if more than 16-bits was used to represent internal physical coordinates. When this internal physical coordinates representation issue was first brought up on the list more than a decade ago as a result of Geoffrey's bad results with zooming, we discussed a number of options. At the time I advocated simply using PLFLT (normally 64-bit floating point) for the type used for internal physical coordinates. Because memory and disk space are cheap now, I see absolutely no fundamental issues with this solution except for the one important issue of plmeta bandwidth where plmeta results that are written in internal physical coordinates would automatically be a factor of 4 larger than the present case where internal physical coordinates are represented as shorts. I think the solution to this dilemma is to typedef a PLINTERNAL type which normally is the same as PLFLT, but for critical plmeta bandwidth cases the user still has the option to build and use a PLplot version that typedefs PLINTERNAL as short. If you think this is a good idea, then using PLINTERNAL essentially wherever short currently occurs in our code would be an extremely widespread change to our code which would have to be tested for a full release cycle. So this is clearly something that could be experimented with on a topic branch but it should not go into the master branch until after the release on Febrary 28th. However, I brought up this issue now since it would be good for Phil to keep this future PLINTERNAL change in mind if he decided to rewrite the present plmeta code in time for this release. 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
