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

> You solved the hard problem--namely the tics.
>
> I think there are really 4 different problems to solve here.
>
> (1)  When / where in the code to do the transformation.  (Ideally, as
> late as possible.)
>
> (2) Intelegent tics.
>
> (3) a variety of transformations of the axis itself.
>
> (4) dynamic exploration of transformations. (currently the L command
> is supported in gnuplot.)
>
> I think viewing doing (1) as a blocker for the other 3 doesn't make
> sense.  The other three are ready to be included in the existing code
> base and are all local changes.  I don't think they in any way make
> doing (1) harder.  Since the other 3 all call the same transformation
> functions, they shouldn't actually have to be changed at all if (1)
> were implemented.

> I think I see how that would work:
>
> Currently:
> Upon "set log x", all stored x values are transformed and on "unset
> log x" they are inverse transformed.
>
> Phase 1:
> Add a scaling "newlog".
>
> Add to AXIS a pointer to a function that transforms the data.  The
> function takes two parameters: the datum to be transformed, and a
> double.  For scaling "linear" or "log" the function is a no-op.  For
> "newlog", the extra parameter is the base of the logs.  Otherwise the
> extra parameter is ignored.
>
> Always do "last-minute" scaling: When plotting a value, call the
> function via the supplied pointer to transform it.
> On "set log x" or "unset prob x" etc., update the function pointer.
> On "(un)set log x", continue to (un)transform the stored data.
>
> Phase 2 (after initial checkout):
> Rename scaling "log" to "oldlog", and rename "newlog" to "log".
>
> Phase 3 (after a major release):
> Delete the "oldlog" commands and the code to (un)transform the stored
> data.
>
> The above only implements standard scalings (linear, log, probability,
> and maybe weibull).  To accommodate a user-defined scaling function,
> the scaling step needs to be able to point to an action table.  We
> could use that mechanism to implement the standard scalings too -
> building the action tables from static strings like "_linear(x,b)=x"
> or "_log(x,b)=log(x)/log(b)".  However, I'm worried that would be too
> slow.  The faster method would be to give the scaling function three
> parameters (datum, extra, and action table), and let the standard
> scaling functions ignore the third parameter.