#2825 Fix incorrect above/below determination in polar filledcurves

[soki goto]

Issue

With filledcurves below/above, plot functions that should be judged as above the bounding line are incorrectly determined as below.

Cause

n lines 1762-1765 of plot_betweencurves, the points index should be i but is incorrectly set to istart.

  double plx = map_x(plot->points[istart].x);
  double ply = map_y(plot->points[istart].y);
  double pux = map_x(plot->points[istart].xhigh);
  double puy = map_y(plot->points[istart].yhigh);

If it were i, the difference between the plot function and bounding line r could be calculated for each point across the entire polygon, enabling correct judgment.
With istart, only the difference at the first point of the polygon is calculated.
This causes incorrect below determination when "the difference at the polygon's first point is 0" and "the entire polygon should be above".

The logic flow is:
1. dy = 0 // (difference between bounding line r and plot function: dru - drl)
2. corners[points].x = (dy < 0) ? 1 : 0 // (line 1813)
3. side = (corners[points].x > 0) ? 1 : -1 // (line 1567)
4. side = -1

This results in an incorrect below determination.

Test Script

  set polar
  set size ratio 1
  set sample 2000

  a = 0.5
  r(t) = 1 / (2 + cos(t * 3))

  plot r(t) with line lw 2 lc 'black', \
      a with line lw 1 lc 'gray', \
      r(t) with filledcurves below r=a lc rgb 'pink' title ' r(t) < a', \
      r(t) with filledcurves above r=a lc rgb 'skyblue' title 'a < r(t)'

I apologize if my submission method or format is incorrect, as I am not familiar with the proper contribution process for this project.

[Ethan Merritt]

Could you please specify which gnuplot version and which terminal types are in use when you see this bug?

Your patch looks reasonable to the eye, but there are some puzzling points.

• In the current development tip (6.1) I can sort of reproduce it in the qt terminal and in postscript output, but not for wxt or x11 or pdf output. The gd terminals produce something odd that doesn't match either your before or after screen shots.

• Since the problem (at least in the development branch) seems to be terminal-specific, I am wondering whether a fix requires changes to the individual terminal code. I.e. your proposed change might work in this particular case but it might be hiding a deeper problem that hits some terminals. And in fact applying this patch does not change the postscript output.

• There was a terminal-specific code change between 6.0 and 6.1 that looks like it might possibly be relevant (commit 410b547e), but I think this is a false lead since your test case doesn't seem to behave differently when I compare running 6.0.3 and current 6.1.

• After the patch, the example is still sensitive to "set sample". For example, try "set sample 925".

[Ethan Merritt]

I am reclassifying this as a bug report so that when a fix is made it can refer to the issue by number.

I now think that the apparent terminal-dependence is actually due to a difference in the precision of coordinates used by different terminals. There is a test later in the code that looks for points where two curves cross. Depending on the coordinate precision, the delta between the two curves may not go to zero. The test needs to allow for that. With that fix in addition to your code change I can no longer find combinations of terminal and "set sample" that obviously fail. I'm not 100% sure that the fix is perfect but it's certainly an improvement.

Thank you for the test case and the proposed fix.

[Ethan Merritt]

Ticket moved from /p/gnuplot/patches/830/

Can't be converted:

• _milestone: Version 6
• _priority: 5

[soki goto]

Thank you for the confirmation and thorough verification.

Could you please specify which gnuplot version and which terminal types are in use when you see this bug?

This may no longer be necessary, but I'll provide the information just in case:

• Terminal: x11
• Version: master (commit: 3114766baee)

Depending on the coordinate precision, the delta between the two curves may not go to zero. The test needs to allow for that.

In my environment as well, it worked properly after considering the precision tolerance in the part that detects curve intersections.