On 2009-08-28 08:22+0200 Werner Smekal wrote: > Hi Alan, >> >> 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? > > No, colors changed, but I still get warnings, and the colors are also still > wrong: > > *** 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 > > I attached a zip file with the output of the pdfqt driver so you can see, > what I'm talking about.
First, I cannot reproduce any of the difficulties/warning messages you are seeing. So finding the solution to this issue is going to require some more experimentation/debugging on your part. Second, please use revision 10355 (or later) for all further investigation. I just now made changes for that revision to output more information in the warning messages to make it easier to identify exactly which part of the code is generating the warning message. Looking at your attached files, as expected, pages 2, 3, and 5 replace the desired colours with red scale (put in by revision 10354) as a fallback and to give a visual warning to accompany the above text warnings for respectively cmap1_blue_yellow.pal, cmap1_blue_red.pal, and cmap1_gray.pal. The above warning messages correspond to the 3rd line (the first data line) in all three files. By the way, I am pretty sure (unless a device driver is really screwed up) that cmap1 palette reading troubles should be device independent. Could you confirm that by trying -dev psc for example 16? The above warning message seem to be only related to the palette files I identified and cmap1_default.pal (used for page 4 of example 16) doesn't appear to be giving you any trouble. On the other hand, the (very) strange thing is example 16 also uses cmap1_gray.pal for the first page, and you didn't report any warning messages for that page. Could you please try some experiments with examples/c/x10c -cmap1 cmap1_*.pal -dev psc -o test.psc to see if you have any problems with the above palette files in that case? >> >> 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.) > > No, it's an Intel Core 2 Duo. Running Mac OS X 10.5.7. > Hmm. That would seem to indicate the trouble you are having reading the palette files on Mac OS X has nothing to do with floating-point errors, and in any case the present code is pretty fire-proof against those. So to summarize the experiments I would like you to try, please see whether -dev psc also produces the example 16 warning messages and please see whether can you reproduce similar issues for example 10 using -cmap1. Once the new warning messages have identified exactly where in the code the problem is occurring, could you please try a gdb session (or printf's scattered around plspal1) to see exactly what is going wrong? I am sorry so much of the work tracking down this issue is on your shoulders, but there is not much I can do here except make suggestions for experiments since I am getting perfect (valgrind-clean and heap-clean) results here. My guess is there is something in the plspal1 code that depends on some assumption that is only true on Linux, but I don't know what that could be. 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
