![]() ![]() Now that I understand the cause of this phenomenon, I will not be surprised if I encounter the same situation in the future. Thank you for detailed explanation about hidden3d situation and difficulty of implementation. I understand that the problem with this issue is that the standard C library specification does not include a stable sort function, and that portable stable sort functions are not available in gnuplot, which is expected to be used in a variety of environments. I really appreciate your efforts on this issue. I am not seeing a real need to address this issue by changing sort algorithms. single-valued with respect to z) identical surfaces like the ones in these toy examples you can solve the problem by displacing one of them by a small delta-z. I am far less familiar with the hidden3d code than the pm3d code, so I might be overlooking an opportunity for some other approach.įortunately, all the examples so far can be solved without changing gnuplot at all. I suppose in extrema you could make the lines of each successive plot incrementally thinner and then select thick lines over thin lines. But that would not correspond to whether the red surface was before or after the green one in the plot command. So it might be possible to modify the sort comparison such that it consistently put, say, red lines in front of green lines. Linetype properties are the only thing I see available as a secondary sort criterion. ![]() I don't think the hidden3d case is fixable in the same way. Anyhow, give it a try and let me know if it solves the issue. Not horrible, but certainly under linux I see no reason anyone would want to take a 5% hit for no visible gain. The downside is a constant 5% increase in memory use for all pm3d calculations. I expect this option to have negligible effect on both the code size and the run time. I only know there is a difference because I dumped the PostScript output to compare line by line. But at the pole the size of the quadrangles goes to zero, so even though the output order is different there is no visible change in the resulting plot. I am guessing that is because the parametric description of a sphere is degenerate at the poles and many quadrangles overlap there. Surprisingly, I do find a difference in one output plot from the full demo set run with or without enabling the new option under linux. But if I didn't mess it up, you should be able to I may have messed up something while modifying the configure file because I'm terrible at that. The code itself is pretty straightforward. I suppose that this has never been a problem because there is no need to draw multiple surfaces that fully or partially overlap in the normal case. I have not checked the situation in other environments (other BSDs, Windows. It is said that glibc uses a kind of merge sort as 'qsort', but I could not find an exact description. On the other hand, I had no problem on Rockey Linux. TheĪs a test, I simply replaced the 'qsort' function with the 'mergesort' function which has the same API as 'qsort' and was able to draw without problems even on MacOS. If two members compare as equal, their order in the sorted array is undefined. The algorithms implemented by qsort(), qsort_r(), and heapsort() are not stable that is, According to 'man', qsort function in the C library of the MacOS system is not stable, I discovered this phenomenon on MacOS environment. Especially, the behavior depends on whether the implementation of the qsort function is stable sort or unstable sort, which does or does not preserve the order of elements of the same value. This is likely due to the fact that the qsort function used for depth sort behaves differently depending on the C language library. Depending on the compiled environment, the depth sort in splot may fail for overlapping surfaces. ![]()
0 Comments
Leave a Reply. |