Brook Milligan <brook@trillium.NMSU.Edu> writes:
> I have finally resolved the differences in the union regression test.
> The problem is that the test uses the float8 table as part of the
> test, and this table turns out to be different among platforms because
> of different behavior with small numbers. Since the float8 part of
> testing unions seemed entirely irrelevant I have changed it to use
> float4, which is not different among platforms.
Tom Lane replied:
It's not? I think you assume far too much about the uniformity of
floating-point hardware.
Bruce Momjian replied:
In fact, float4 normally has much _worse_ floating point portability
than float8.
float4 can't seem to get even simple number right.
I was just basing my idea on the fact that there are no
platform-specific special-cases for the float4 regression test. I
guess no one has submitted them? If it is really that bad, why aren't
there more special-cases so the regression tests don't fail? Would
this not help new users?
Thomas Lockhart replied:
I had included float8 in this particular regression test to exercise the
int4->float8 "promotion" since float8 is a "preferred type". Don't know
why float4 should in general have different or better behavior than
float8 wrt conversions and rounding; you may just be lucky on your
platform.
However, the float8_tbl is pretty ugly after the float8 regression test.
How about defining a new table which has better behaved numbers? I would
prefer that to eliminating float8 from the test altogether. I'll bet
that floating numbers like 1.1 are represented OK on Brook's machine,
and that the problems are with the 1e-200 numbers?
Yes, the small numbers (like 1e-200) are handled as zero and enter the
float8 table, making the later union results different.
Anyway, there is nothing magical about using float4. I chose it
arbitrarily because I was under the impression that it was better
behaved because of lack of special casing. Clearly a wrong
assumption.
The important point here, though, is not really about float4 versus
float8; float8 is fine and now I see that it is better in fact. The
important point is that a table that is not special-cased should be
used whenever possible (and I still recommend including something
along the lines of my earlier paragraph to prevent this in the
future).
If the float8 data type works better, we should make a float8 table
that is uniform across platforms in order to test the union code.
There is really no point in including the boundary cases of float8
into a test of union.
Perhaps a better solution is to insert into the union.sql code a
float8 table creation, fill it with well-behaved data, and then use
that table in the union test.
Cheers,
Brook
