ST_Extent when cast to box3d flipflops

[robe]

I'm not sure how to explain this, but I see this behavior on my 2.0 and 1.5 (PG 8.4, 9.1) on my windows 7.0 64-bit (32-bit PostGIS). Saw the same behavior on a Windows 7.0 32-bit (running PostGIS 2.0, didn't have 1.5 to test).

However my 8.4 32-bit on windows 2003 server running PostGIS 1.5 does not exhibit this behavior.

SELECT ST_Extent( 'LINESTRING( 1.121333 2.2567,3.3456 4.4567 )'::geometry )::box3d

The issue is that the answer to the above alternates between On my 64-bit 1.5 install on 8.4

-- note the e+180 e+214
BOX3D(1.121333 2.2567 5.21970604560393e+180,3.3456 4.4567 1.9161093301878e+214)

and

BOX3D(1.121333 2.2567 1.35832574246381e-312,3.3456 4.4567 1.39071360148373e-309)

on my 64-bit windows 7 (running 32-bit PostGIS 2.0 alternates between:

BOX3D(1.121333 2.2567 0,3.3456 4.4567 0)

BOX3D(1.121333 2.2567 1.44721314518794e-312,3.3456 4.4567 3.88199318618405e-080)

Granted the differences are small (except for the e+ cases), but why it changes answer like the wind is a mystery.