[postgis-users] extent changed a little in rc3

[strk at refractions.net]

On Mon, Mar 14, 2005 at 08:39:09PM +0100, Bernhard Herzog wrote:
> strk at refractions.net writes:
> 
> > On Fri, Mar 11, 2005 at 05:40:24PM +0100, Bernhard Herzog wrote:
> >> 
> >> I've finally found some time to test the postgis 1.0.0rc3 with Thuban.
> >> The test suite stumbled over a change in the return value of the extent
> >> function.  The return value has fewer digits in the coordinates of the
> >> bounding box and they now differ enough from the values expected by the
> >> test cases to make some tests fail.  
> >
> > We changed that to avoid bug reports stating "output box is not the same
> > of input box".
> 
> In something like the following I guess:
> 
> select 'BOX(1.1 2.2, 1.2 2.3)'::box2d;
>                                   box2d                                   
> --------------------------------------------------------------------------
>  BOX(1.10000002384186 2.20000004768372,1.20000004768372 2.29999995231628)
> (1 row)

Yes!

> The Python developers had a similar problem.  Before Python 2.0 (or
> thereabouts) the value of 1.1 was reported as 1.1 in an interactive
> python session.  Later the way floating point values were printed in the
> interactive session was changed to give at least as many decimal digits
> as would be needed to get exactly the same binary floating point value
> when converting the decimal representation back to a float.
> 
> This has the advantage that newbies stumble over the fact that some
> numbers that they are accustomed to being exact in decimal cannot be
> expressed exactly in binary floating point.  Without this they
> invariably stumple over this when they implement more complex algorithms
> using point numbers and wonder why the result isn't exactly what they
> expected, at which point it becomes much more complicated and thus more
> work to explain what goes wrong.
> 
> As a result of that change in Python, the python tutorial has been
> extended with an appendix about floating point numbers so that it's easy
> to point the newbie to a resource where they can learn more about it:
> 
> http://docs.python.org/tut/node16.html
> 
> 
> So, the upshot this is: I think it's better to report reasonably
> accurate values in the textual representations of postgis types than
> trying to hide the effects of binary floating point.

You're probably right, it was a bad idea changing it...
Anyone else's opinion on this ?

> > The box your obtaining is actually correct, it's the output
> > representation which has less digits then before (change introduced in RC3).
> 
> Yes.  I noticed that when I checked the sources.
> 
> > As long as you're not ascii-transferring the box the overlap test should
> > still hold. Try:
> >
> > 	SELECT
> > 		extent('POINT(1.0000001 2.0000002)') &&
> > 		'POINT(1.0000001 2.0000002)'::geometry;
> 
> Well, that doesn't really prove much.  If the bounding box of
> POINT(1.0000001 2.0000002)'::geometry were actually wrong you'd be
> comparing the same wrong values with each other.

Oops, you're right. Well something like this should prove it:

	-- this should be a polygon with an hole
	-- (extent returns a box2d, guaranteed to be *at least*
	--  as big as the geometry - usually larger)
	SELECT difference(extent('POINT(1.000001 2.0000002)'), 
		'POINT(1.0000001 2.0000002)');

	-- this should be the GEOMETRYCOLLECTION EMPTY
	SELECT astext(difference('POINT(1.0000001 2.0000002)',
		'POINT(1.0000001 2.0000002)'));

--strk;

> 
>    Bernhard
> 
> -- 
> Intevation GmbH                                 http://intevation.de/
> Skencil                                           http://skencil.org/
> Thuban                                  http://thuban.intevation.org/
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users