Re: Puzzling aspect of logscale implementation

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

On Friday, November 05, 2010 03:35:50 pm Hans-Bernhard Bröker wrote:
> On 05.11.2010 19:50, Ethan Merritt wrote:
> > I have encountered a problem while trying to predict or adjust axis scaling
> > in advance of actually issuing a plot command.   The problem is that the
> > "set log" command sets the field AXIS.base, but the corresponding field
> > log_base is not initialized until a subsequent plot command invokes the
> > macro AXIS_INIT2D.   Instead it is set to zero.
> 
> It's _initialized_ to zero.  It's set to zero only by the AXIS_INIT*D 
> macros themselves, and that only if the axis is not logscaled.
> 
> And it would appear to happen so late to allow implementing the 
> 'islog_override' argument for AXIS_INIT3D.

That doesn't seem relevant.  The islog_override flag turns off log scaling
for 3D parametric axes [which can never be turned on anyhow so the whole
mechanism seems unnecessary...]. It does this independent of the previous values
of either AXIS.base or AXIS.log_base, so it shouldn't care about whether or not
they were properly initialized earlier as well.

> > Why would you ever want to have AXIS.log_base out of sync with AXIS.base?
> 
> Well, that "you" might be me, I guess.  I started axis.[ch] as a 
> renovation project.  That was finished by the release of gnuplot 3.8e, 
> exactly 10 years ago this week.  But most of that code I just refactored 
> from lots of individual arrays (min_array[], log_base_array[], ...) into 
> a single array of structs, so the code you're looking at is actually 
> even older than that.
> 
> OTOH, none of the code using log_base is or ever was meant to be used 
> before AXIS_INIT* anyway, so it's not really out of sync.

Sure.  But now I do have a reason to use it before a plot command is issued.
Hence the problem.
 
> > Can anyone think of a reason why it isn't correct to always set log_base
> > at the same time the base itself is set?  I.e.,  on every call to "set log".
> 
> One part of the problem is: what value do you set it to when the axis is 
> _not_ logarithmic?  In theory, it would have to be negative infinity --- 
> but that can't be done reliably.  Zero is the next best thing.
> > And everywhere that it is set to zero should be removed, since zero is
> > never a legal value.
> 
> No, it shouldn't.  Precisely because it's never legal for a log axis, 
> it's just about the perfect signal for "this axis is not logarithmic". 

It could have been used that way as a signal.  But it isn't.
As I already noted, no place in the current code tests the value of log_base.
Instead there is a separate boolean flag AXIS.log, which is a cleaner
solution.

So - historical artifact.  That's fine. I just wanted to check if I had
missed something.

	Ethan