Hi Alan, On Sun, 2009-04-26 at 23:39 +0100, Alan W. Irwin wrote: > On 2009-04-26 21:43+0100 Steve Schwartz wrote: > > > I'm not at all complaining about your suggestion. Indeed, the reason for > > my posting is because I had already thought about a do-it-ourselves > > approach and therefore wondered if someone else had also either > > encountered it or was more familiar with the internal plplot workings > > and would have the expertise to offer a more elegant and robust > > solution. > > I first want to address this issue from my perspective as one user of PLPlot > in a scientific research context. > > _From my user perspective_ the status quo is fine. Looking at example 1 the > (x10#u-2#) (where "x" stands for the times symbol) is pretty ugly wherever > you put it.
I agree that there is some ugliness no matter where the x10^nn is placed. My starting point was merely that, for our particular application, some places were uglier than others. I would add that beauty, and ugliness, is in the eye of the beholder. > Thus, my opinion is adding functionality to allow the user > freedom to move that ugliness around may not be adding much value. Perhaps > we should instead just document that scientific notation labelling as a last > resort when you have badly scaled plot axes. I think for an individual writing their own plplot code to generate a single plot frame this is probably true. E.g., if the plot is temperature in the solar corona then it would be better to divide by 10^6 and label the temperature axis "Temperature (MK)" rather than "Temperature (K) (x10^6)". Of course, for temperatures in the thousands of Kelvin lower down in the atmosphere, "Temperature (kK)" looks a bit strange, and I guess you would manually if necessary use fixed point labelling if you could. The example plots I showed are not completely typical for our software in that often there are more panels containing other parameters. These are gathered from a variety of source files and held by us as data objects on a working list, to be used for subsequent analysis and plotting. The plotting interface we have written will let a user literally drag'n'drop as many objects as they like onto a gui and then hit the plot button to generate something like what I sent out. We offer considerable control over the placement and appearance, to meet presentation and publication standards, but strive to empower our users to be able to visualise their data as qiuckly as possible in the initial stages. This speed and ease is central to the interactivie working with the data (as opposed to careful preparation for the one, final publication plot of a selected set of parameters/results). So we are at the mercy of the data supplied by external sources and the remote use of software written by us through our gui-driven application. Our software WILL allow you to scale data (and will keep track of the units) but this is initially only done so that data from different sources can be meaningfully combined. > Since I have always thought it was ugly, I avoid that scientific notation > "last resort" by properly scaling my axes. What I mean by that is I use log > (z) or z/10#un#d as the variable being plotted and label it as such where > "n" is chosen appropriately to give a good scaling. I far prefer the log (z) > idea, but when I do scale my axes by some power of 10, the programming of > that is trivial so there might not be much call for a PLplot API that does > that. I acknowledge my user perspective might be wrong here, but I have > never had trouble generating properly scaled plots to avoid the scientific > notation so I am having trouble figuring out why it might be difficult in > other contexts. I've tried above to give some insight into our context. Programming a specific example is, as you suggest, usually trivial. Programming automatic handling of the generic case is rather trickier. And it can be hard for us to second guess what our own user community would want - there's a compromise between "pretty vs ugly" on the one hand and "conventional vs scaled" units on the other. Many solar physicists, for example, hate measuring the Sun in Mm (Mega-metres) and prefer to use cm (for which a power of 10 is hard to avoid); in other circumstances, of course, they often measure things in units of the Sun's radius for the same aesthetic reasons as yours. > Putting on my PLplot developer hat now, the trick is to balance the various > user perspectives and plotting needs while trying to keep our API as > non-bloated as possible. (The advantage of a non-bloated plotting API is it > makes PLplot easier to learn and easier to test and maintain.) Yep, understood. > On the whole, I think we are doing pretty well with this balancing act. Agreed; we're quite happy to have adopted plplot for this reason; and we stuck with pgplot before that for a long time for exactly the same reason of a compact stable api. > In this case, I have some doubts as a user that the above two API > possibilities would add much value, but I could be wrong because I am only > one user of PLplot. I don't think it's a question of right or wrong - that's too black and white. After all, the plplot interface is larger than its pgplot predecessor precisely because you wanted more functionality, more power. Everyone will draw their own line somewhere; for some, the simplest use of plplot, with half a dozen lines of code to handle the box, labelling, etc., etc., and data is adequate, and hacking one of the simple plplot examples is all that is required, to their no-doubt delight. Then if they wish they can delve deeper into the API and do more things, fine tuning, etc. I think the question you raise about bloating code is probably more relevant to maintenance and testing than the user API, though I would not wish to undervalue those considerations. I'm not going to beat anyone over the head with this matter; I raised it to see if it would be worth pursuing by someone. I would point out, though, that the existing API provides the user with control over the size and position of almost everything (box, ticks, labels, titles, displacement, font, ...). Adding user control over the otherwise imposed placement of "x10^nn" would seem to be not illogical. It could be done by re-using the familiar concepts of displacement, justification, and orientation that are presently employed for axis labelling. Yours, Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7900 The Blackett Laboratory E-mail: s.schwa...@imperial.ac.uk Imperial College London Office: Huxley 711A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
