Greg Stark <st...@mit.edu> writes:
> For completeness, here's the regression tests from the conrttrib
> modules. I haven't looked into why earthdistance is coming up with
> such odd results but I suspect it all comes from the same arithmetic
> source. I don't see any surprising internal dependencies on ieee
> floating point.
I think the tests that are giving unexpected results are simply
doing things that are numerically unstable. For instance, in the
first test that's giving a problem:
SELECT longitude(ll_to_earth(90,0))::numeric(20,10);
! longitude
! --------------
! 0.0000000000
(1 row)
SELECT longitude(ll_to_earth(-45,0))::numeric(20,10);
--- 365,373 ----
(1 row)
SELECT longitude(ll_to_earth(90,0))::numeric(20,10);
! longitude
! ----------------
! 180.0000000000
(1 row)
the very first thing that happens inside ll_to_earth is
"cos(radians(90))". The exact answer to that of course should be zero,
but it never will be zero because pi/2 isn't exactly representable in
anybody's float arithmetic. On my Intel machine it gives
6.12323399573677e-17, and it would be far from astonishing if the VAX's
arithmetic instead gives some very small negative value. Such a sign
change would result in the observed flip.
> For what it's worth there are a number of mentions in the docs of
> platforms that have non-ieee semantics behaving differently so I
> wouldn't say we don't support such platforms. If we could avoid the
> test failures without weakening the tests for other platforms that
> would be nice. But I don't see any obvious way to do that.
Yeah. The NaN and Infinity behavioral changes seem like a big problem.
And even if we wanted to carry alternative expected-files, how would
we maintain them? Can't ask people to spin up a Vax emulator to submit
a patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
