The reasoning behind the specific fixed choices in the library are no longer accessible to me. I do know that prior to the exponential notation mods, plplot would give really ugly plots when in the extremes of small and large number ranges. I do recall spending a lot of time futzing with various choices, finally ending with "Good enough! Time to get some real work done".
Extra choice to the user is always good. Better defaults are also good. Determining an indisputably better solution in either case, especially the latter, is sometimes difficult. :) Sorry I can't be of more help but I'd have to basically rediscover my previous decision making anyway, even if I had the time to look into it. So a good learning experience for any developer that decides to take this on. On Monday, November 16, 2009 at 11:43:37 (-0800) Alan W. Irwin writes: > To Maurice and Geoffrey: > > I have questions for you below concerning a PLplot style change that would > give users more freedom about deciding whether or not exponential notation > is used in axis labels. > > On 2009-11-14 17:47-0800 Alan W. Irwin wrote: > > > While investigating the old bug report > > https://sourceforge.net/tracker/?func=detail&aid=844858&group_id=2915&atid=102915, > > I managed to reproduce the problem with the following python script: > > > [...] > > plsyax(10000, 0) > [...] > > plwind(0.00, 1.00, 0.00, 0.08) > [...] > > If I change the plwind call to > > > > plwind(0.00, 1.00, 0.00, 0.10) > > > > the issue goes away. > > I have investigated this issue further. The pldprec code predicts digmin, > the largest possible label length for the given range (which in this case is > slightly negative to slightly more than 0.08). Normally, "0.08" would > correspond to digmin of 4 (this digits count includes the sign and decimal > point), but the code calculates digmin = 5 since the range includes negative > values (which handles the possibility of a label at, say, "-0.01"). > > The plsyax call above insures pldprec is called for the y axis with > digmax=10000. However, that digmax value is interpreted further using > the following macro values > > #define MAX_FIXDIG_POS 6 > #define MAX_FIXDIG_NEG 4 > > which are the ceiling on digfix calculated from digmax depending on whether > we are dealing with positive or negative exponents. In this case, digfix is > 4 since 0.08 corresponds to negative exponents. Thus, digmin > digfix which > is why there is no way for users to get anything other than exponential > notation for > > plwind(0.00, 1.00, 0.00, 0.08) > > So fundamentally, this issue is a fixed style issue imposed by the > choice of the above macro values. > > My own feeling on style issues is we should have good defaults. (Our code > sets > > if ( plsc->xdigmax == 0 ) > plsc->xdigmax = 4; > > if ( plsc->ydigmax == 0 ) > plsc->ydigmax = 4; > > if ( plsc->zdigmax == 0 ) > plsc->zdigmax = 3; > > when the library is initialized which I think is probably okay.) However, I > also believe we should allow users freedom to impose their own style if they > want. You could increase that freedom by increasing both MAX_FIXDIG_POS and > MAX_FIXDIG_NEG or you could give complete user freedom by simply dropping > MAX_FIXDIG_POS and MAX_FIXDIG_NEG and setting digfix = digmax. This > complete freedom implies the user can avoid exponential notation if he so > desires regardless of the range by using pls[xyz]ax appropriately. If the > result is ugly, then he should reconsider the large first argument he is > using for pls[xyz]ax or else simply use our default values. > > Maurice and Geoffrey, the above macros defining MAX_FIXDIG_POS and > MAX_FIXDIG_NEG go back to before 1995 (!) in our code so I am wondering if > you guys can remember the historical justification of this fixed style > decision. In any case, would you now be willing to go along with giving > users more style freedom on whether the axis labelling is done with > exponential notation or not? If the answer is yes, please let me know what > MAX_FIXDIG_POS and MAX_FIXDIG_NEG values you think are appropriate or > whether we should ignore them and simply use digfix = digmax. > > Same questions for other PLplot developers here if you feel strongly > about this style issue. > > 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 > __________________________ -- Maurice LeBrun ------------------------------------------------------------------------------ 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
