-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect result of the function bg::intersection() #663
Comments
What compiler and what version of the compiler is this What compilation flags did you use, especially what optimisations? |
I also compiled with MSVC2012 Ver11.0.51106.01. |
It's quite important to know at least if you do non-optimised debug build or you do optimised build (Release in Visual Studio speak). |
DEV-C + + 5.11 : TDM-GCC 4.9.2 32-bit Release. |
Thanks for checking it's not optimisation related.
For some/many cases, that is what you should do, because without that macro defined, the algorithms will perform rescaling to integer for more numerically robust solution (default behaviour). geometry/include/boost/geometry/core/config.hpp Lines 25 to 29 in b930d33
You may still need to define the macro in order to disable the rescaling for some/edge cases as you discovered in the previous issue you reported #662. I think this case can be closed. |
I have two code. code1
code2:
|
The first case looks like that: red - poly1 With
The CW/CCW point order does not affect the result. Tested with VS2017. |
The second case: As @linshu77 said it's the other way around WRT
|
This is my code with the define BOOST_GEOMETRY_NO_ROBUSTNESS,
It can be compiled by DEV-C + + 5.11,Boost version: 1.72.
The answer should be 0, but it's 27.
However, if I delete the "#define BOOST_GEOMETRY_NO_ROBUSTNESS",
the answer will be correct.
The text was updated successfully, but these errors were encountered: