On 2009-08-27 12:57-0700 Alan W. Irwin wrote: > On 2009-08-27 09:05+0200 Werner Smekal wrote: > >> * example 16 has wrong colors. The following warning messages are print to >> the screen: >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format 0.0 1.0 1.0 1.0 1.0 0 >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0 >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format 0.0 0.0 0.0 0.0 1.0 0 > > These warnings are evidence of more floating-point comparison issues that > ocurred in plspal1 which I should have spotted when I fixed a similar issue > that Valery Pipin found for cmap1_default.cmap. > > I believe I have now solved all these plspal1 floating-point comparison > issues completely using a macro for the needed and oft-used programme > fragment to deal with such issues (revision 10353). Also, I have made a > much better fallback (gray scale rather than segfault) when the requested > cmap1 palette file is completely wrong. Could you try again, please, to see > if the above warnings are gone? > > Out of curiosity, what hardware were you using when you ran into the above > warnings? I suspect it wasn't Intel/AMD. (That hardware uses 80-bit rather > than 64-bit registers to store intermediate floating-point results. That > leads to higher than normal floating-point precision and fewer > floating-point comparison issues. The downside is that if you test > exclusively on Intel/AMD, you may not notice the effects of problematic code > which is subject to floating-point comparison issues.)
I have now (revision 10354) in plctrl.c implemented a fuzzy range check in cmap0_palette_read (to complement the one in plspal1), implemented some code cleanup and reorganization, and implemented a better job of freeing fs in plLibOpenPdfstrm that is allocated by plGetName. The valgrind results are perfect (*) (no memory errors, all heap blocks were freed) for a large range of wacko conditions for cmap0 and cmap1 palette files. (* Of course you only achieve this perfection if you use one of our devices such as -dev psc or -dev svg which does not call external libraries which often leave some blocks allocated after the external library is closed). This code should now be flame proof regardless of what blunders users might think up when editing palette files and regardless of floating-point errors in palette calculations. (Hmm, sounds like "famous last words".... :-) ) 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
