Greg Stark <st...@mit.edu> writes:
> Attached is the pg_regress diff. I believe they are all user-visible
> effects of non-iee fp math though I would have expected the rounding
> to work right and I'm not clear how gist ends up returning rows in a
> different order.
I concur that these are generally unsurprising given what we know about
VAX arithmetic. The tests that give different integer rounding results
are specifically checking whether the platform does round-to-nearest-even
as specified by IEEE. It's not surprising that pre-IEEE platforms might
not have chosen that behavior. The other stuff is due to different
range and precision of FP math, get_floatX_infinity() returning HUGE_VAL
rather than a true infinity, get_floatX_nan() throwing a SIGFPE, etc.
The gist tests in question appear to me to be underdetermined by design
--- for example, the first one is
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5))
order by p <-> point(0.2, 0.2);
and so there is nothing wrong with ordering (0.15,0.15) and (0.25,0.25)
differently, because they're exactly the same distance from (0.2,0.2).
I'm not sure why we've not seen more platform-specific failures on that
test. Given that it's only existed since Nov 2014, maybe we shouldn't
assume that it's been through the wars yet. I'm tempted to change the
reference point to (0.201,0.201) or so, so that the correct sort order
is unambiguous. Heikki, did you make it like that intentionally?
We could eliminate the unexpected FPEs on use of "NaN" if we configured
get_floatX_nan() to throw a "platform does not support NaN" error rather
than intentionally executing an undefined operation. However, I'm not
sure why we'd bother unless we're going to make VAX a supported platform,
and personally I don't want to change the other tests that are failing
here.
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
