From: Philipp K. J. <ja...@ie...> - 2009-05-25 03:11:18
|
I'd like to add one thing to Ethan's list: The current log-scale does not play well with the "smooth" algorithms, such as "smooth frequency". I have not analyzed the root cause of this behavior in detail, but I can certainly see how it comes about given the entire complex of issues that Ethan has scoped in his email. So, there is yet another reason why it would be nice to be able to apply transformations for display purposes as late in the game as possible, so that earlier operations on the data (such as "smooth freq" or "smooth kdens") succeed. Best, Ph. On Saturday 23 May 2009 09:40:49 am Ethan Merritt wrote: > On Saturday 23 May 2009, Hans-Bernhard Bröker wrote: > > Dean Foster wrote: > > > I've been working on adding some other transformations to > > > gnuplot. > > > > I'm afraid you could have saved yourself most of the effort. There's > > already a patch out there doing that. See > > > > http://sourceforge.net/tracker/?func=detail&aid=1757226&group_id=2055&ati > >d=302055 > > True. But that patch repeats what I consider to be a design error > in how the transform is implemented. Like the current log scale code, > it transforms the data as it is read in, and stores only the transformed > data. That limits what you can do interactively with a plot that is > already on the screen. I would much rather see a patch that rearranges > the order of operations so that the original, untransformed, data is > stored internally, and the transform is applied at the time of > mapping it to plot coordinates. Some advantages that I see are: > > - There is no loss of precision as you toggle the transform on/off > interactively. The exact original data is always available. > NB: This was less an issue back when the log/unlog code was > first written, because replotting necessary required re-reading > from the original data file. But now we can refresh/replot the > graph directly from the internal copy, it is an extra limitation > if you have to go back to the data file. > > - An extreme case of the above occurs when the transform is toggled > in an external viewer module rather than in the gnuplot core. This > is partially implemented for the canvas terminal driver, but it > would be a whole lot easier if the _untransformed_ coordinates were > sent to the external viewer, along with the transform and its inverse. > > - The code would be a lot cleaner if the transform code was entirely > localized to the coordinate mapping functions map_position() and > map_3dposition(). Right now we have extra code scattered all over > the place, and extra fields in various data structures, just to > handle the special case of data that is stored as log(data). > As currently written, all this special case code would need to be > extended for each new transform. Conversely, if the transform were > localized to a single set of map/unmap routines, virtually all of the > special case code could go away and data structures could go away. > > - The axis tic placement code for log-scale tics is complex, and is > the source of some of our longest-standing bug reports. I particularly > like the idea of being able to avoid a similar mess in implementing > new transforms. I suspect that simplifying the tic placement code would > all by itself be sufficient reason for storing untransformed data > internally. > > - A generalized transform/untransform step in the coordinate mapping would > make it trivial to handle arbitrary transforms provided by the user. > > So I would very much welcome any patches the work towards implementing > a generalized framework for applying an arbitrary transform at the > stage of coordinate mapping. Once that is in place, the log/unlog > transform becomes just one special case and most (all?) of the special > case code can go away. > > > > Since I haven't seen any patches being > > > > > > sent on this news group so far, I'm not sure what the style is > > > either. > > Please submit patches via the SourceForge gnuplot project site. > > --------------------------------------------------------------------------- >--- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is > a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |