Re: Fwd: Patch 1757226 : probability scaling and axes

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

>> > Ethan A Merritt writes:
...
>> > Furthermore, this would present an excuse^H^H^Hopportunity to
>> > re-work how data values are stored internally.  Right now setting
>> > log-scaling on an axis causes the corresponding data coordinate to
>> > be transformed and stored as the log.  This creates great headaches
>> > if you want to toggle the log-scaling and redraw the plot from the
>> > data previously read in.  I think it would be much cleaner and more
>> > flexible to store the original coordinate value on input, and only
>> > apply the log- or other scaling during plot generation.
>> 
>> Yes!  One reason I didn't take my patch any further was that the "last
>> minute scaling" revision ought to be done first.
>
>I had come to the opposite conclusion.
>I figured to leave the existing log-scale code in place, as you 
>suggested above, while adding a new more general mecanism that worked
>on the original stored coordinates.  Once the general mechanism was
>in place and working, the old log-scale code could be removed without
>ever having to modify it to work  with "last-minute" scaling.

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.

           - Jim Van Zandt