gnuplot-beta

Interesting bug: relative offset + log scale = problem

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

Someone on the usenet group reported a problem that boils down to
  set log y
  plot newhistogram "title",   <foo>, <baz>, ...

The result is an error return
  histogram has y coord of 0; must be above 0 for log scale!

Now in fact the histogram itself is fine. This error message
is triggered by attempting to place "title", which has an 
implicit offset of (0,0) relative to whatever auto-generated
position the plot layout code settles on. 

  graphics.c 4891:    map_position_r(&(histogram_opts.title.offset),
                                     &xoffset_d, &yoffset_d,
                                     "histogram");

and then in map_position_r we trip over:

  switch (pos->scaley) {
  case first_axes:
    {
      double yy = axis_log_value_checked(FIRST_Y_AXIS, pos->y, what);
                  ^^^^^^^^^^^^^^^^^^^^^^
      *y = yy * axis_array[FIRST_Y_AXIS].term_scale;
      return;
    }

I can fix this particular mess-up by initializing the offset 
explicitly to be a character offset rather than a y1axis plot offset.
That's fine. 
 
But the larger question is, why should the code invoke a range
check on the value of a relative position in the first place?

An increment of zero should be legal, log scale or not.
Isn't the check against axis_log_value_checked() in map_position_r()
a mistake?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Interesting bug: relative offset + log scale = problem

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> Someone on the usenet group reported a problem that boils down to
>   set log y
>   plot newhistogram "title",   <foo>, <baz>, ...
> 
> The result is an error return
>   histogram has y coord of 0; must be above 0 for log scale!
> 
> Now in fact the histogram itself is fine.

How is this fine?  If one of the histogram bins has a value of 0, log(0) is undefined.  Do you mean there is special code to deal with this case?

This error message
> is triggered by attempting to place "title",

By title you mean a title for each individual bin?  The title for the plot should always be layed out according to a linear scale of screen coordinates I would think. 

Dan

Re: Interesting bug: relative offset + log scale = problem

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

On Wednesday 16 August 2006 11:13 am, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > Someone on the usenet group reported a problem that boils down to
> >   set log y
> >   plot newhistogram "title",   <foo>, <baz>, ...
> >
> > The result is an error return
> >   histogram has y coord of 0; must be above 0 for log scale!
> >
> > Now in fact the histogram itself is fine.
>
> How is this fine?  If one of the histogram bins has a value of 0,
> log(0) is undefined.  Do you mean there is special code to deal with
> this case?

The error message comes from the title.
Remove the title, no error message - the histogram itself has
no problem.

The error message is totally a false alarm, based on checking
the "offset" value of the title string.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Interesting bug: relative offset + log scale = problem

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 16 August 2006 11:13 am, Daniel J Sebald wrote:
> 
>>Ethan Merritt wrote:
>>
>>>Someone on the usenet group reported a problem that boils down to
>>>  set log y
>>>  plot newhistogram "title",   <foo>, <baz>, ...
>>>
>>>The result is an error return
>>>  histogram has y coord of 0; must be above 0 for log scale!
>>>
>>>Now in fact the histogram itself is fine.
>>
>>How is this fine?  If one of the histogram bins has a value of 0,
>>log(0) is undefined.  Do you mean there is special code to deal with
>>this case?
> 
> 
> The error message comes from the title.
> Remove the title, no error message - the histogram itself has
> no problem.
> 
> The error message is totally a false alarm, based on checking
> the "offset" value of the title string.

Oh, yes now I see what you mean.  Well, the test should be against the eventual placement, not the offset, right?  Writing a patch for this would take a bit, but I don't see how one can do arithmetic on offsets using a logarithm scale, i.e., log(x+y) != log(x) + log(y).  I would guess this:

	    x = map_x((hist->start + hist->end) / 2.);
	    y = xlabel_y;
	    x += (int)xoffset_d;
	    y += (int)yoffset_d + 0.25 * term->v_char;

has to come before this:

	    map_position_r(&(histogram_opts.title.offset), &xoffset_d, &yoffset_d,
			   "histogram");

in some fashion.

Dan

Re: Interesting bug: relative offset + log scale = problem

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

On Wednesday 16 August 2006 12:26 pm, you wrote:

> Well, the test should be against 
> the eventual placement, not the offset, right? 
> I would guess this:
>
> 	    x = map_x((hist->start + hist->end) / 2.);
> 	    y = xlabel_y;
> 	    x += (int)xoffset_d;
> 	    y += (int)yoffset_d + 0.25 * term->v_char;
>
> has to come before this:
>
> 	    map_position_r(&(histogram_opts.title.offset), &xoffset_d,
> &yoffset_d, "histogram");

That would be absurd.
The whole *point* of map_position_r() is to calculate for you
what needs to be added to the x,y coordinates.  If you're going
to do that everywhere in-line, then there is no need for
the map_position_r() routine at all.

I am leaning towards the idea that map_position_r() needs a
top level check on entry for zero offsets.
Who cares whether it's zero characters, zero plot units,
or zero something else?
Zero is zero.

But it may also be true that map_position_r() should never
do range checking, even for non-zero offsets.  The combination
of   base_position=BIGNUM  and offset=(-BIGNUM)  may be
nicely in range even if neither would be allowed individually
as a coordinate value.



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Interesting bug: relative offset + log scale = problem

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 16 August 2006 12:26 pm, you wrote:
> 
> 
>>Well, the test should be against 
>>the eventual placement, not the offset, right? 
>>I would guess this:
>>
>>	    x = map_x((hist->start + hist->end) / 2.);
>>	    y = xlabel_y;
>>	    x += (int)xoffset_d;
>>	    y += (int)yoffset_d + 0.25 * term->v_char;
>>
>>has to come before this:
>>
>>	    map_position_r(&(histogram_opts.title.offset), &xoffset_d,
>>&yoffset_d, "histogram");
> 
> 
> That would be absurd.
> The whole *point* of map_position_r() is to calculate for you
> what needs to be added to the x,y coordinates.  If you're going
> to do that everywhere in-line, then there is no need for
> the map_position_r() routine at all.

Well, perhaps there isn't... But first, if we are talking efficiency, why is the following inside the inner loop?

	if (hist->title.text && *(hist->title.text)) {
	    double xoffset_d, yoffset_d;
	    map_position_r(&(histogram_opts.title.offset), &xoffset_d, &yoffset_d,
			   "histogram");

Aren't the values of xoffset_d and yoffset_d going to be the same every pass?  Why keep calculating them?


> I am leaning towards the idea that map_position_r() needs a
> top level check on entry for zero offsets.
> Who cares whether it's zero characters, zero plot units,
> or zero something else?
> Zero is zero.

Well, this is sort of my point.  As far as placement of text (or color box, or whatever) why does that need to be in a logarithmic scale?  Now, I can understand if the user options have manual placement, then fine.  As with tics, etc. the user needs to think in terms of the logarithmic scale and do a bit of computing; a bit of arduous work.

OK, if we are saying the user can enter an _offset_ for title placement, well then I don't see how we can expect the user to enter that as a logarithmic value pertaining to a logarithmic scale.  Ignoring the mathematical limitations for now, from a conceptual standpoint, that would mean the visual offset is different for each value.  However, that is not how the code works.  In the code I see and as you describe the idea is to compute the offset and have it be the same no matter the histogram bin height.  So ostensibly, we're taking a quantity we expect the user to enter as some kind of logarithmic offset and then convert that back to something working on a linear scale?  (It is difficult to follow sometimes exactly what scale gnuplot is using without trial and error.)

What is the sense of working with logarithmic values if the offset is always going to be a constant?  Why can't the user indicate an offset using, say, a linear screen scale value?

Dan

Re: Interesting bug: relative offset + log scale = problem

[<br...@ph...>]

Daniel J Sebald wrote:

> Well, this is sort of my point.  As far as placement of text (or
> color box, or whatever) why does that need to be in a logarithmic
> scale?  

Because on a logarithmic axis, that's the only data scale there is
(but see 'graph', 'char' or 'screen' coordinate systems).

> OK, if we are saying the user can enter an _offset_ for title
> placement, well then I don't see how we can expect the user to enter
> that as a logarithmic value pertaining to a logarithmic scale.

The same way he can enter an increment for logarithmic tics: as a 
factor, instead of the usual summand.

> Ignoring the mathematical limitations for now, from a conceptual
> standpoint, that would mean the visual offset is different for each
> value.  

Only if we did it even wronger than the code dug out by Ethan.

> What is the sense of working with logarithmic values if the offset is
> always going to be a constant?  

None.  Which is why that's not what we're doing.

 > Why can't the user indicate an offset
> using, say, a linear screen scale value?

He can.  But he should be *allowed* to specify it in data coordinates, too.

Re: Interesting bug: relative offset + log scale = problem

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:

> The same way he can enter an increment for logarithmic tics: as a=20
> factor, instead of the usual summand.

OK, you say "factor".  Here is what I sent to Ethan and what I think you =
are saying:

...

That is

y_title =3D alpha * y_hist;

Then

 log(y_title) =3D log(y_hist) + log(alpha)

and right there the log(alpha) is the "offset" we are searching for.

Is THIS what the user is thinking of when saying offset?  I'm guessing no=
, because in all likelihood the user would never enter an "offset" (i.e.,=
 alpha) of zero and it should be invalid.  If that is how we compute "off=
set", then the user will typically be entering something like 1.1 or 1.05=
, etc.

...

You are saying that the code is then correct (except for moving the compu=
tation of x_offset and y_offset outside the loop for efficiency) and 0 is=
 an invalid user entry.  Perhaps we should have an error message:

  For logarithm scale, 0 is not a valid factor.  Try a factor of 1.

Dan

Re: Interesting bug: relative offset + log scale = problem

[<br...@ph...>]

Ethan Merritt wrote:

> I am leaning towards the idea that map_position_r() needs a
> top level check on entry for zero offsets.
> Who cares whether it's zero characters, zero plot units,
> or zero something else?
> Zero is zero.

Not on a logarithmic axis it ain't.  On a logarithmic axis, offset zero 
is actually negative infinity.  If the user wanted an offset of 
_visually_ zero, then on a log axis the gnuplot way of saying so would 
be to specify an offset factor of 1.

> But it may also be true that map_position_r() should never
> do range checking, even for non-zero offsets.  

Then you should be glad --- because it doesn't actually do range 
checking.  It does illegal value checking on logarithmically scaled 
values, which is a different thing.

This is ultimately a usage error we're looking at, possibly caused by 
insufficient documentation.  In gnuplot, the tradition is that 
increments to logarithmic values are specified as values that have to be 
logarithmized, following the way 'set xtics <incr>' behaves on log axes:

	set log x
	set log y 2.0
	set ytics 16
	plot [1e-3:1e3] x

The offsets of axis labels and titles should work the same way.

Re: Interesting bug: relative offset + log scale = problem

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

On Wednesday 16 August 2006 03:19 pm, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> > Zero is zero.
>
> Not on a logarithmic axis it ain't.  On a logarithmic axis, offset
> zero is actually negative infinity.  If the user wanted an offset of
> _visually_ zero, then on a log axis the gnuplot way of saying so
> would be to specify an offset factor of 1.

I concede the point.

I will apply the minimal fix of initializing the default histogram
title structure to specify 0 character units for the offset.

If the user explicitly changes it to something else that breaks=20
in the presence of a log-scaled axis, that's their own headache.

> increments to logarithmic values are specified as values that
> have to be  logarithmized, following the way 'set xtics <incr>'=20
> behaves  ...

> The offsets of axis labels and titles should work the same way.

Probably.  But those are already correctly defaulting to character
units.  I'm trying very hard not to touch any of the core code at
this point.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA