I wrote:
>> I'm very hesitant to apply a volatile-qualification approach to
>> eliminate those issues, for fear of pessimizing performance-critical
>> code on more modern platforms. I wonder whether there is a reasonable
>> way to tell at compile time if we have a platform with 80-bit math.
>
On 8/25/19 4:23 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 8/20/19 8:59 AM, Peter Eisentraut wrote:
>>> Running the regression tests on mingw32, I get the following diff in
>>> circle.out:
>>> - | <(3,5),0> | <(1,2),3> | 0.60555127546399
>>> + | <(3,5),0> |
I wrote:
> I'm very hesitant to apply a volatile-qualification approach to
> eliminate those issues, for fear of pessimizing performance-critical
> code on more modern platforms. I wonder whether there is a reasonable
> way to tell at compile time if we have a platform with 80-bit math.
Hmmm ...
Andrew Dunstan writes:
> On 8/20/19 8:59 AM, Peter Eisentraut wrote:
>> Running the regression tests on mingw32, I get the following diff in
>> circle.out:
>> - | <(3,5),0> | <(1,2),3> | 0.60555127546399
>> + | <(3,5),0> | <(1,2),3> | 0.605551275463989
> I
Peter Eisentraut writes:
> I can confirm that SET extra_float_digits TO -1 in circle.sql fixes the
> original complaint.
Cool. It did on dromedary, but that doesn't necessarily prove much
about other compilers :-(
> I don't understand this stuff enough to be able to provide a good source
>
On 2019-08-23 15:50, Tom Lane wrote:
> Peter Eisentraut writes:
>> The circle.sql file already has SET extra_float_digits TO 0, and a few
>> other files have other settings with different values. Are we content
>> to use various numbers until it works in each case, or should we try to
>> use
Emre Hasegeli writes:
> I couldn't test if it helps, but another solution may be is to rip out
> pg_hypot() in favour of the libc implementation. This was discussed
> in detail as part of "Improve geometric types" thread.
Hm ... the problem we're trying to fix here is platform-varying results.
> I poked at this a bit more. I can reproduce the problem by using
> -mfpmath=387 on dromedary's host (fairly old 32-bit macOS); although
> I also get half a dozen *other* failures in the core regression tests,
> mostly around detection of float overflow. So I'm not quite sure that
> this is
Peter Eisentraut writes:
> The circle.sql file already has SET extra_float_digits TO 0, and a few
> other files have other settings with different values. Are we content
> to use various numbers until it works in each case, or should we try to
> use some consistency?
The one in rules.sql
On 8/20/19 8:59 AM, Peter Eisentraut wrote:
> Running the regression tests on mingw32, I get the following diff in
> circle.out:
>
> @@ -111,8 +111,8 @@
>WHERE (c1.f1 < c2.f1) AND ((c1.f1 <-> c2.f1) > 0)
>ORDER BY distance, area(c1.f1), area(c2.f1);
> five | one | two
On 2019-08-22 18:19, Tom Lane wrote:
> What I suggest doing is reducing extra_float_digits to -1 for this
> specific test. Changing the contents of circle_tbl seems like it'd have
> more consequences than we want, in particular there's no guarantee that
> we'd not hit similar issues in other
I wrote:
> Peter Eisentraut writes:
>> Do we care to do anything about this? Pick slightly different test data
>> perhaps?
> Picking different test data might be a good "fix". Alternatively, we
> could try to figure out where the discrepancy is arising and adjust
> the code --- but that might
Peter Eisentraut writes:
> On 2019-08-20 14:59, Peter Eisentraut wrote:
>> Running the regression tests on mingw32, I get the following diff in
>> circle.out:
...
> OK, the problem isn't the new output routines. The result of the
> computations is actually different. The test itself is new in
On 2019-08-20 14:59, Peter Eisentraut wrote:
> Running the regression tests on mingw32, I get the following diff in
> circle.out:
>
> @@ -111,8 +111,8 @@
>WHERE (c1.f1 < c2.f1) AND ((c1.f1 <-> c2.f1) > 0)
>ORDER BY distance, area(c1.f1), area(c2.f1);
> five | one | two
Running the regression tests on mingw32, I get the following diff in
circle.out:
@@ -111,8 +111,8 @@
WHERE (c1.f1 < c2.f1) AND ((c1.f1 <-> c2.f1) > 0)
ORDER BY distance, area(c1.f1), area(c2.f1);
five | one | two | distance
15 matches
Mail list logo
