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