sorry meant "no doubt that the point" not "no count that the point"
On 12 September 2016 at 21:39, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: >>>> I'm still of the opinion that the notcrossed function should not use >>>> the 2 pixel fuzziness. At this point in the drawing we are dealing in >>>> integer pixels and we need only an epsilon test I think. I think the >>>> best fix is to change this. There are some sticking plaster solutions >>>> that would hide the problem but not really fix it in my opinion. I >>>> would really like to change the notcrossed function unless anyone has >>>> some really strong objections? >>> >>> >>> My opinion is this is an extraordinarily tricky topic where all the >>> currently active fill code (i.e., the part of the code not currently >>> removed by the C preprocessor) needs to be completely reviewed and >>> potentially rewritten. Also, I think the fuzziness logic (with all >>> bugs fixed in that code) should stay just in the interests of >>> providing some tolerance for numerical rounding errors. For example, >>> even the article <https://en.wikipedia.org/wiki/Point_in_polygon> >>> talks of providing some numerical tolerance. Note also, such >>> tolerance is certainly required for the integer case since minute >>> rounding errors in the floating point calculations that decide, for >>> example, whether a point is inside or outside a polygon can shift >>> integer results around by +/- 1. >>> >>> I have a topic branch where I have already taken some substantial >>> steps along the above ideas (including at least one bug fix in our >>> current fuzzy logic in notcrossed). I temporarily halted work on that >>> topic some time ago, but assuming you can provide a test example that >>> triggers fill bugs regardless of compiler or optimization level, I >>> plan to take up that topic again where the first order of business >>> will be to compare (using imagemagick image differences) updated fill >>> algorithm results versus 5.11.1 results for all our standard examples >>> that use fill in some way. (That test should turn up any unusual fill >>> artifacts in our examples that are generated by bugs in the original >>> or revised fill algorithm, and once that test is implemented it should >>> be done for any fill change from now on.) In addition, of course, I >>> will look carefully at your example to make sure the revised fill >>> algorithm produces the correct result for it. >>> >>> Assuming you are able to provide the requested example which triggers >>> the fill bug regardless of rounding issues, and the above >>> plan meets with your approval, I would plan to start working on this >>> topic again just after the current release is out the door. >>> >>> Note also there are still a number of relatively small issues I would >>> like to address for this release, but because of the break I mentioned >>> above, I made little progress on those this summer so that release >>> deadline is still indefinite and at least a month or two away. >>> > I agree that this is tricky, but feel this is something we can deal > with without being too troublesome. Algorithms and code already exist > to do this consistently - we're not the first to have to deal with it. > In fact here is a 7 line C implementation that deals with the ray > hitting a vertex correctly, but doesn't give any warning about if the > point is close to or on a segment. > > I still don't understand why we need two whole plplot units of > fuzziness. I understand that we round and that can give us up to two > pixels of error. But surely we just accept that and work with the > rounded polygons as if they were exact - in fact they are exact > because they use integers. > > for example we wish to plot two rectangles which end up with internal > coordinates of the opposite corners of (200,400.2),(600,600.4) and > (200,600.4),(600,800.1). We round these to give (200,400),(600,600) > and (200,600),(600,800). Now there is absolutely no count that the > point (350,600.2) is in the second rectangle. Of course if we were > using the original coordinates this point would have been in the first > rectangle. But we are not plotting the original coordinates, we are > plotting the rounded coordinates and that is what matters - the > coordinates we are plotting. > > I would clearly like to get this fixed properly, but in the meantime > would anyone object if I apply a sticking plaster fix for this as it > is something I have hit about half a dozen times over the last six > months - I presume this is because I've been plotting some really high > resolution data. So I do really need to avoid the issue for now. > > Phil ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
