#1777 Arrow not using second coordinate system with set link on
Using version 5.0.3 on windows, using the second coordinate system for setting an arrow with set link on is not producing the desired results.
Suppose that we run the following:
set xrange[0:4]
set link x2 via x/4.0 inverse x*4.0
set x2tics
set xtics nomirror
set arrow 1 from second 0.9, graph 0 to second 0.9, graph 1 nohead
plot x, x**2 axes x2y1
Here we set the range from 0 to 4 and link the x2 axis so that it runs from 0 to 1 based on the mapping. We then set an arrow that should run vertically the length of the graph at 0.9 on the second axis (90% of the way across the graph as this axis runs from 0 to 1). However, when plotting this it is creating the plot saved as actual.png. We see that it is actually using the first coordinate system to draw the arrow.
This only occurs with the set link command. If we had done set x2range[0:1] instead of using set link, the arrow would have plotted fine. In fact if we follow up the above with
unset link x2
replot
it produces the desired results (saved as desired.png), which is what we want.
Additionally, the plot command produces the error message
warning: could not confirm linked axis inverse mapping function
min: 0 inv(via(min)): 0 max: 4 inv(via(max)): 4
warning: could not confirm linked axis inverse mapping function
min: 0 inv(via(min)): 0 max: 4 inv(via(max)): 4
warning: could not confirm linked axis inverse mapping function
min: 0 inv(via(min)): 0 max: 4 inv(via(max)): 4
even though this should be an easy inverse to confirm.
The warning messages are legitimate. They are telling you that since x=0 at one end of the range, the inverse mapping 1/x is undefined. The mapping is still valid over the rest of the range.
I cannot explain the mis-placement of the arrow, other than to say that I can reproduce the problem in 5.0.3 as released, but not with the current cvs source for either 5.0 or 5.1. I will look into it further.
I just tested with the development version of 5.1 that I compiled current up to 3/21, and am also seeing the correct behavior. I wonder if another change already fixed that somehow. I don't have the 5.0 cvs source (I only know how to get the 5.1 one), so can't test there.
Why is 1/x involved in the inverse mapping? In this example, the inverse is 4 * x and the original mapping function is x/4. There is no division by x involved. Is there something that I am missing here?
Ah, you are correct. My mistake. That pair of functions should work even at x=0. I have edited the text in my original response.
Hmm. In current CVS for 5.1 I don't get that error message, but in CVS for 5.0 I do get the error message even though the output plot is correct. There is one entry in the ChangeLog for 5.0 indicating a typo in 5.0.3 that affected linked y/y2 axes but I don't see why that typo would cause this bug seen for the x2 axis. So I don't know yet what's going on, but I think there remains a problem with the 5.0 source that has been fixed as a side effect of some other change in 5.1.
Looking at the source code, I can see where the error message seems to be fixed in the 5.1 source. I don't know why the original error has been fixed there as well (and in the 5.0 development version), but the error message is fixed in 5.1.
In the clone_linked_axes function in axis.c (line 2193 in the develeopment version as of 3/21 and 2135 in the released 5.0.3 source), there is a check that seems to look at the relative error between the mappings. In the 5.0.3 source, there is certainly a division by 0 error there in this case, or at least a division-by-very-close-to-zero error, which of course, can vastly inflate floating point approximation errors. In the development source, an extra condition is added to see if the mapping is perfect before checking the relative error. I don't think that fixes the division by 0 possibility in all cases (when the mapping is very close to perfect, but not quite [due to approximation errors], and one endpoint is 0), but it does in this case.
That is probably a change that should be made to the 5.0 line as well.
Again, I am not sure where the placement of the arrow ends up fixed, and if it fixed in the 5.0 development line as well, it has nothing to do with this change in the clone_linked_axes function.
Last edit: Matthew Halverson 2016-04-14
Yes. I've just back-ported that modification to the relative error checking and the spurious errors in current 5.0 cvs go away.