Re: "Polygon not closed" warning - rounding error?

[Karl R. <ra...@un...>]

Am 28.11.2014 um 20:49 schrieb Philipp K. Janert:
> On Fri, 28 Nov 2014 20:41:06 +0100
> Karl Ratzsch <ra...@un...> wrote:
> 
>> Am 28.11.2014 um 19:38 schrieb Philipp K. Janert:
>>
>>> Am 28.11.2014 um 18:58 schrieb Philipp K. Janert:
>>
>>>> set object 1 polygon from -0.9,0.9 rto 0.8,0 rto 0,-0.8 rto -0.8,0
>>>> rto 0,0.8 set object 2 polygon from  0.1,0.9 rto 0.8,0 rto 0,-0.8
>>>> rto -0.8,0 rto 0,0.8
>>
>> Why not leave out the last step? The polygon closes itself by itself.
> 
> [snip]
> 
>>
>>> After all, using straight equality in floating
>>> point arithmetic is rarely the right thing to do.
>>
>> True. That´s why a polygon should get closed by returning to the
>> origin, not to a place that would be the origin if we had infinite
>> precision.
>>
>> So i´d say there´s nothing to be done about this, except that "set
>> object polygon" could get an additional "close it" option, that
>> suppresses the extra-vertex warning.
> 
> Well, I am questioning the purpose of the warning,
> in particular if it is implemented using straight
> floating-point equality. (I'd even argue that 
> a floating-point comparison using '==' amounts to
> a "bug".)
> 
> I think that there are in fact two options:
> - the close-it option you suggest (which would be a
>   new feature)
> - suppressing the warning if the length missing 
>   vertex is "small" compared to numerical accuracy
>   (which would be proper floating point programming)

No. Do what the example in the docs does, and don´t give five corners
for a four-corner object. Why would you want to?

If you really don´t know how many corners your object has beforehand,
you´ll have to do the math to find out, or indeed derive the precision
of the calculation. gp can´t do that for you, it doesn´t know how you
determined the coordinates.

  Karl