Re: Fwd: Patch 1757226 : probability scaling and axes

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 20 May 2008 15:40, James R. Van Zandt wrote:
> > Are you still interested in this patch and
> > would be willing to revivify it? ;-)
> 
> Certainly.  I may need CVS access renewed, depending on how my account
> gets straightened out.

That's easy enough.  If you end up with a different SourceForge ID,
just let me know and I'll modify the develop list accordingly.

 
> Ethan A Merritt writes:
> 
> > I would really like to see this implemented in the general form
> > mentioned on the TODO list. That is, I want a mechanism for mapping
> > an arbitrary monotonic function f(x) onto a display axis.
> > Both log(x) and probability(x) could become special cases of this
> > general code rather than being separate parallel code paths.
> 
> Yes, with a couple of caveats.  I expect it will take some tuning
> before people are happy with log scaling in all cases.  In the mean
> time, I expect we should maintain both mechanisms.  My code for
> probability scaling makes use of the analytic expressions for forward
> and inverse scaling, plus the known range of values (open interval
> between zero and one).  Some of the underlying code handles the more
> general case where only one function is supplied, and it's inverted
> numerically.  I haven't tried to figure out the range automatically,
> though.  We'll have to decide how much of that information we expect
> from the user.
> 
> > 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 that order of doing things has less chance of breaking things
as the new scheme is developed.  But I have not looked seriously at
what it would require to modify the existing log-scale code first.
Maybe it's not so bad.

-- 
Ethan A Merritt