Re: Adding some new transformations to gnuplot (arctan and power laws)

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&atid=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
gnuplot-beta@...
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta