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

[James R. V. Z. <jr...@co...>]

I wrote
...
> > monotonic. For example, I'd like to implement f(x)=1/x, so I could
> > label spectra in both energy and wavelength units. However, the range
> > requirement could be either "x>0" or "x<0", and if there are both
> > positive and negative values in the data, the program would be hard
> > pressed to make the right choice.
> 
> Actually, I view this as a "monotone" transformation.  It just happens
> to wrap at zero rather than wrap at +infinity as most monotone
> functions do.  :-)   

Actually it does not satisfy either of the monotonic requirements
   whenever x ≤ y, then f(x) ≥ f(y) 
or else
   whenever x ≤ y, then f(x) ≤ f(y)

> So if you are using the transformed space and
> you have both positive and negative values, the natural graph is to
> put +infinity in the middle of the graph.   No code else where even
> has to know about this weirdness--it just sees a set of points to
> plot.

True.  And sometimes it would make sense - e.g. for the position of a
virtual image.

> I tried implementing this in my version, but there are lots of range
> checking that is done in untransformed coordinates.  This would have
> to be switched to checks done using transformed coordinates.  So my
> implementation just ducked this issue.  But I think the right answer
> is to have a plot with +infinity in the middle.  So the axis would
> look something like:
> 
>  --------+-------+-----+-----+------+-------+---------+--
>          5       10    20  infty   -20     -10       -5

Yes, this could work.  With some manual customization for a particular
transform.  But it would be a challenge to get autoranging to find
this solution for a general user-specified transformation.

BTW I proposed
> We might go through three phases here.  (1) implement only fixed
> transforms for which we have analytic inverses, so the pointer could
> be to a C function.  (2) allow user-defined functions, but demand 
> that the user also supply the inverse function.  Here we would need a
> pointer to a parse table.  (3) Allow the user to
> omit the inverse function, falling back on the rational interpolation.
...
> and for user supplied transformations
> 
>      {un}set user scale {x|y...} func(dummy)  
>      {unscale func2(dummy)}
>      {rangecheck func3(dummy)}

I would like to generalize this to make the forward transform
optional:  

      {un}set user scale {x|y...} {func(dummy)}
      {unscale func2(dummy)}
      {rangecheck func3(dummy)}

where at least one of the forward and reverse transform must be specified.

There are cases where the inverse transform has an analytic form, but
the forward transform does not.  Arguably this is true for the
probability transform, which is defined as

           set user scale x invnorm(x)

The more "natural" way to specify this might be

           set user scale x unscale norm(x)

Likewise if you want the transform for a probability distribution
where you have a function to calculate the CDF, but not its inverse.

      - Jim Van Zandt