gnuplot-beta

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

[Philipp K. J. <ja...@ie...>]

Forwarding HBB's response to the list...

(and my response below)


Begin forwarded message:

Date: Fri, 28 Nov 2014 19:31:46 +0100
From: Hans-Bernhard Bröker <HBB...@t-...>
To: "Philipp K. Janert" <ja...@ie...>
Subject: Re: "Polygon not closed" warning - rounding error?


Am 28.11.2014 um 18:58 schrieb Philipp K. Janert:
> If I issue the following two commands (in a fresh 5.0rc3 session):

FWIW, 4.6pl6 Win32 does the same.

> 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

> then gnuplot complains that the second polygon is not closed (and
> that gnuplot is adding a vertex).

> Is this due to internal roundoff, so that the endpoint != startpoint
> in floating point arithmetic?

Somewhat obviously: yes.  This is a relatively clear example of

	In computing, 10 times 0.1 is hardly ever 1.0

> It did confuse me for a while (did I do something wrong?). Might it
> be possible to suppress such warnings?

Only at the cost of getting a non-closed polygon, which would be a good 
deal worse.


PKJ: I disagree. If the warning is in fact due
to round-off (which I don't know - it might be
due to a bug in the code, for instance; I did
not look at the implementation), then it would 
be possible to suppress such warnings if the 
length of the "missing vertex" is sufficiently
small (compared to the rest of the polygon?).

After all, using straight equality in floating
point arithmetic is rarely the right thing to do.

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

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

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.

>> then gnuplot complains that the second polygon is not closed (and
>> that gnuplot is adding a vertex).
> ....
> PKJ: I disagree. If the warning is in fact due
> to round-off (which I don't know - it might be
> due to a bug in the code, for instance; I did

It´s rounding :

gnuplot> print 0.1 + 0.8 - 0.8 - 0.1
-2.77555756156289e-017

> 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.

  Karl

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

[Philipp K. J. <ja...@ie...>]

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)

> 
>   Karl
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards with Interactivity, Sharing, Native Excel Exports, App
> Integration & more Get technology previously reserved for
> billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________ gnuplot-beta mailing
> list gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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