Here I saw several peoples who wants a floating version of clipper
Angus J. uses integer instead floats to deals with robustness.
In fact, integer values means fixed point arithmetic instead of floating point arithmetic.
As explained in documentation, you just need to use a scale factor. For example, I use a 10.000 factor gives me a 0.1µm precision that is strong enough for NC milling or 3D printing.
And I think that using integer (fixed point arithmetic) coordinate is still a good idea for another important reason.
Floating point arithmetic is a bad idea when you deals with geometry. Because in floating point arithmetic, the precision is depending on the value, so each time you translate an object, there are rounding errors. So in floating point arithmetic, each time you translate an object you get deformation!
Indeed, in fixed point arithmetic, you get the same precision regardless of object position.
That is to say, fixed point arithmetic XY plane is a regular grid plane, but if you use floating point XY coordinates, your XY plane is a strange and insane “variable pitch” grid. So we should never use floating points to deals with geometric problems.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well...Angus does integerisation of coordinates after using floating point precions to evaluate intersections...
But the integerisation of coordinates does help in cuttin down on the number of output polygons without affecting the areal output numerically.!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The downside is that this integerisation lowers precision. If floats would be used throughout the library, this integerisation is not needed. I mentioned this a while ago to Angus: one cause for minor self intersections can be this integerisation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also float->integer and integer->float cause rounding errors. It is safe to make comparisons using floating point coordinates inside Clipper because bigger float is bigger float the same way bigger integer is bigger integer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a complex topic. Generally, it does not matter whether you use floats or ints, as long as you compute your predicates correctly. With machine supported integer types and with math expressions of limited tree depth, it is easier done with integers.
Dear,
Well the predicates are prone to integer<r>-float conversion cooking
recipes.I have dpne extensive scaling and rescaling of vertex inputs using
anugus code to insure areal equivalence of output with the ancient vatti
like(with turing class bugs) double precision clipper.Even for a visual
equivalence with extreme low values of x,y coordinates a scaling up by 2^8
was required to gulp up sqaured corner outputs.
My note only refers to the step used internally...which used double
precision dx/dy to evaluate intersections. My explorations with extreme
dense polygon contours(12 + subect(700+), 15 + clips(500+) indicate that
speed advantage is rapidly lost if scaling is done, as the input integers
become big big.
This is a complex topic. Generally, it does not matter whether you use
floats or ints, as long as you compute your predicates correctly. With
machine supported integer types and with math expressions of limited tree
depth, it is easier done with integers.
Hi
Here I saw several peoples who wants a floating version of clipper
Angus J. uses integer instead floats to deals with robustness.
In fact, integer values means fixed point arithmetic instead of floating point arithmetic.
As explained in documentation, you just need to use a scale factor. For example, I use a 10.000 factor gives me a 0.1µm precision that is strong enough for NC milling or 3D printing.
And I think that using integer (fixed point arithmetic) coordinate is still a good idea for another important reason.
Floating point arithmetic is a bad idea when you deals with geometry. Because in floating point arithmetic, the precision is depending on the value, so each time you translate an object, there are rounding errors. So in floating point arithmetic, each time you translate an object you get deformation!
Indeed, in fixed point arithmetic, you get the same precision regardless of object position.
That is to say, fixed point arithmetic XY plane is a regular grid plane, but if you use floating point XY coordinates, your XY plane is a strange and insane “variable pitch” grid. So we should never use floating points to deals with geometric problems.
Thanks
well...Angus does integerisation of coordinates after using floating point precions to evaluate intersections...
But the integerisation of coordinates does help in cuttin down on the number of output polygons without affecting the areal output numerically.!
The downside is that this integerisation lowers precision. If floats would be used throughout the library, this integerisation is not needed. I mentioned this a while ago to Angus: one cause for minor self intersections can be this integerisation.
Also float->integer and integer->float cause rounding errors. It is safe to make comparisons using floating point coordinates inside Clipper because bigger float is bigger float the same way bigger integer is bigger integer.
This is a complex topic. Generally, it does not matter whether you use floats or ints, as long as you compute your predicates correctly. With machine supported integer types and with math expressions of limited tree depth, it is easier done with integers.
https://people.eecs.berkeley.edu/~jrs/meshpapers/robnotes.pdf
https://www.cs.cmu.edu/~quake/robust.html
https://www8.cs.umu.se/kurser/TDBAfl/VT06/algorithms/BOOK/BOOK4/NODE184.HTM
Dear,
Well the predicates are prone to integer<r>-float conversion cooking
recipes.I have dpne extensive scaling and rescaling of vertex inputs using
anugus code to insure areal equivalence of output with the ancient vatti
like(with turing class bugs) double precision clipper.Even for a visual
equivalence with extreme low values of x,y coordinates a scaling up by 2^8
was required to gulp up sqaured corner outputs.
My note only refers to the step used internally...which used double
precision dx/dy to evaluate intersections. My explorations with extreme
dense polygon contours(12 + subect(700+), 15 + clips(500+) indicate that
speed advantage is rapidly lost if scaling is done, as the input integers
become big big.
On Fri, Mar 23, 2018 at 8:16 PM, Vojtech Bubnik OK1IAK ok1iak@users.sourceforge.net wrote: