Re: PostgreSQL for VAX on NetBSD/OpenBSD

Greg Stark <stark(at)mit(dot)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