Re: PostgreSQL for VAX on NetBSD/OpenBSD

Greg Stark <stark@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