[postgis-users] extent changed a little in rc3

[Bernhard Herzog]

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)


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.


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

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/