gnuplot-beta

Puzzling aspect of logscale implementation

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

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.
So until you actually issue a plot command, anything that tries to use
the macros AXIS_DO_LOG or AXIS_UNDO_LOG triggers a
divide by zero or other error because AXIS.log_base is 0.

Why would you ever want to have AXIS.log_base out of sync with AXIS.base?

Why is it reset to zero in several places?  Zero is never a correct value
to use in applying the log scale, and I don't see any place in the code
that uses zero/non-zero as a flag to control something else.

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".

And everywhere that it is set to zero should be removed, since zero is
never a legal value.  If an initialization value is needed,  log(10) makes
a whole lot more sence than 0.

So, proposed patch:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/set.c   2010-10-11 14:30:23.000000000 -0700
+++ gnuplot-new/src/set.c       2010-11-05 11:43:27.000000000 -0700
@@ -2229,6 +2229,7 @@ set_logscale()
 	        if (set_for_axis[axis]) {
                axis_array[axis].log = TRUE;
                axis_array[axis].base = newbase;
+               axis_array[axis].log_base = log(newbase);
            }
         }
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Anyone see a problem with this?

	Ethan

Re: Puzzling aspect of logscale implementation

[Hans-Bernhard B. <HBB...@t-...>]

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.

> 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.

> 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". 
And since axes are non-logarithmic by default, that's the right initial 
value.

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

Re: Puzzling aspect of logscale implementation

[Hans-Bernhard B. <HBB...@t-...>]

On 06.11.2010 00:16, Ethan Merritt wrote:
> On Friday, November 05, 2010 03:35:50 pm Hans-Bernhard Bröker wrote:

>> 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...].

Well, for what it's worth, 'fit' does run AXIs_INIT3D of the u and v 
axes with the override turned off...

>> 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.

So maybe whatever that undisclosed reason actually is needs to be 
handled differently.

>> 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.

But setting it to a "legal" value like log(10) would kill the option of 
using it that way for good.  I fail to see how that's any better.

Re: Puzzling aspect of logscale implementation

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

On Saturday, November 06, 2010, Hans-Bernhard Bröker wrote:
> On 06.11.2010 00:16, Ethan Merritt wrote:
> > On Friday, November 05, 2010 03:35:50 pm Hans-Bernhard Bröker wrote:
> 
> >> 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...].
> 
> Well, for what it's worth, 'fit' does run AXIs_INIT3D of the u and v 
> axes with the override turned off...

Are you saying that the 3D fit code uses, or can use, log scale on
a parametric variable?  What does that even mean?  
Can you suggest a test case that I should check before removing what
seems to be an unused block of code?





> 
> >> 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.
> 
> So maybe whatever that undisclosed reason actually is needs to be 
> handled differently.
> 
> >> 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.
> 
> But setting it to a "legal" value like log(10) would kill the option of 
> using it that way for good.  I fail to see how that's any better.
>