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